I’m looking at ways to provide quick, clear visual feedback to a user for various states of operation.
I’m using the Pad object a lot as a button (either momentary or toggle). When there’s a state change, I can update the Pad name and/or color to show the change. The design of the Pad object looks like there would be room for a second line of text above the name. Is that something that is planned?
Alternately, is there a way to have underlined text or ‘block reverse’ text (text in black surrounded by a white block - kind of like when you highlight something)
For now I can use the group labels above controls for additional info, so it’s not critical; I was just curious.
when I give the function setStep to a list control, then the stepNumber is allways lagging one behind, except on the boundaries, where it eventually reaches the desired value.
I thinkwe had this behavior in earlier versions, but then it was solved
function setStep(valueObject,value)
stepNumber = value
print ("Step Number = "…stepNumber)
end
PS: I found that the long tail of debugger messages can be stopped by quitting and reentering the “lua & tools” section. But then it would be useful the lua repositions itself on the line number you were when you quit the screen, for fast workflow purposes
could it be the saving or viewing of saved revisions isn’t active yet in the Beta environment?
Been saving revisions systematically in the last days for Electra One App
but none of them appear in the ‘previous revisions’ page:
Don’t know how he’s doing it exactly, but there’s always been the raw materials to create LFOs using the timer functions. I might have even created an example at one point (I know the tc 2290 preset uses a timer to simulate an auto-increment by holding down a pad)
Indeed, the LFO’s dont come out of the box, but you can program them, and that’s what I do: I let the Electra One check every 20 ms if there is a new value to transmit.
The 4 modulations will be:
until this morning I was able to segregate MIDI sending from parameter mapping, which is great to change a midi value on a synth temporarily without changing it on the parameter map. But since today I see the control of a parameter, controlled by the E1 LFO changing, as if it is caught in a MIDI loop.
Could it be something has changed so the E1 is now reading instantly any CC it receives while it has been sending it itself? As a result of this loop, my LFO’s is no longer working, but constanty resetting the original value on the E1 to one of the extreme values (typically 0 or 127)
Another find: double tapping does reset the value of a control to its default, but it doesn’t trigger the function attached to the control
hmm, there has not been any change done recently. I had to take a break to other circumstances. Please check if you have any type of loop there. I will review what I can from my side.
Electra web app is using Google Firebase as the backend. Saving of revisions hits a hard limit of Firebase when the amount of “revision data” grows too big. I am working on an adjustment. Please note, the project itself is saved safely.
It is not an endless loop. It is just all the messages that Electra sends to the web app. I assume it happens when you load a complex preset.
For some reason it takes really long time to the browser to write the messages to the screen. I am looking at it. Hitting the Clear button (in the logger window) should get rid of the messages and speed it up - if you do not need the messages of course…
Not yet. I would like to support standard html/css color names. There is an issue with that though. if I do that in the same way as it was done in fw 2.2, the color names (in Lua I mean) would consume substantial amount of memory. To do that correctly, I need to add read only constants to Lua, so for now I am staying away from that.
Does this trigger any LUA functions attached to the pad? I think I ended up deciding to treat the pad as momentary and then change title/color as needed versus using a toggle. This allows me to dynamically change what the user sees for the pad function without invoking a function call because of a parameter change.
The need is that if I use the same pads to trigger different types of actions, i would like the pads to remember and set their state as it was for a particular target.
For example, if I use a pad to support Osc 1/2/3 on/off, I wanted the visible state of the pad to represent the state of each oscillator as it was selected. So, if I change the focus from Oscillator 1 to Oscillator 3, the pad should change to show whatever state set for Oscillator 3.
For my use case, it seems to be better to handle the need with momentary and then keep track of state inside the code.
