GUI elements stall and CV fails with hardware knob control
Reporting two issues together, because I believe they are related…
When a plugin parameter is mapped to a hardware knob, any realtime-updating GUI elements (i.e. especially meters) stall.
If such a situation exists in a pedal board with CV plugins assigned internally to control something else, and if there are a lot of realtime-updating GUI elements, the CV control fails.
start the transport rolling (leftmost Duo X button) - that gets the sequencer running, which toggles the switch via CV, producing an intermittent output tone.
twiddle the two upper-right knobs simultaneously (these just operate the non-functional Tiny Gains at the bottom of the board) - watch the sequencer to make sure it doesn’t move, because the CV gate will only fail if the realtime-updating GUI elements DON’T CHANGE for a while.
the CV gate will fail in about 5 seconds.
go into the parameters of the Toggleswitch and change the CV trigger for switch 1 to “1 lfo” - you’ll see that this fails as well, so this bug is not only related to a (sequenced) CV gate.
also, if you start disconnecting the Tiny Gains at the top, one row at a time, you’ll gradually get to a point where it’s very difficult to keep the realtime GUI update from happening once in a while (you’ll start to see the sequencer jump slots) - if that happens before CV fails, it seems that the system recovers enough to prevent CV failure.
Expected/suggested solution
Ideally, realtime GUI updating would continue smoothly while controlling things with hardware knobs. However, realizing that audio function is more important than visual GUI elements, is there a way to make it make it such that GUI stalling at least doesn’t break CV control. If the Duo X is running untethered (without a connection to the browser-based GUI editor), none of this is a problem – we don’t see GUI stalling of course, but also (in issue 2) the CV control does not fail. So, as the system stands, this type of pedalboard will ONLY run properly when the Duo X is untethered.
Additional information
Note: I’ve done less testing with this issue on my Dwarf, but it appears the same situation exists - that device just has a higher tolerance before failure - i.e. it’s more difficult to make GUI elements stall completely for a protracted period of time.
so, once you’ve started the transport rolling, you hear the tone being turned on and off by the CV gate (or by the LFO), right? then you will know when the CV fails by hearing the tone change to a steady state, because the CV is no longer turning it on and off. note that it might be slightly tricky to get it to fail – you have to be twiddling both of the hardware knobs constantly enough to prevent the GUI from updating for a while. you can judge if you’re successfully stalling the GUI by watching the sequencer – it has to stay stuck on only one time “slot”. if it jumps to a new slot, that means that there has been a tiny break in your knob twiddling which has allowed the GUI to run briefly, and that allows the CV process to “catch up” and not fail. it only takes 5 or 10 seconds of continuous stalling for the CV to fail.
are you trying this on a Duo X? that pedalboard is all set up for testing on a Duo X. if you load it on a Dwarf, you will have to assign two hardware knobs to the two unconnected Tiny Gain plugins at the bottom of the board - then those will be the ones you twiddle. you’ll also have to start the transport rolling of course - on the Dwarf, it will come up already assigned to the middle footswitch on the Dwarf. …but then, i’m seeing the same behaviour on my Dwarf as on the Duo X.
…and, yes: @S_Righteous believes this problem only came up with the 1.13 upgrade.
Yes, I was, even on an LE - yours is also LE, right?
…I guess my problem was indeed not fully understanding your description…I didn’t try it with audio, just visually I was expecting it to stop showing up. I will try it again asap
So down the road when this bug gets fixed, should I assume someone would post that in this thread? (I would get a notification) Or should I just periodically check for new OS updates and check the log to see if this bug fix was in that update?
I have tested a few pedalboard - using the ones in our original thread and older ones I saw this issue with and the issue indeed has not occurred, I believe this is now fixed.
I should however mention that there may be a new gremlin in this update because loading pedalboards takes a very long time, and I’ve had this process stall where I had to reboot my mod and reconnect via GUI.
I was loading the very simple test pedalboard which @plutek uploaded to show this issue, and that process froze, it just kept saying ‘loading pedalboard’. Reconnecting didn’t work the first time, but eventually rebooting the device and reconnecting did work.
that is tricky then…
I think the issue here is too many web gui updates already happening while the pedalboard is still loading, which delays the final “ready” state.
So it is worth trying skipping the dynamic plugin port updates while a pedalboard is still loading, and resume them afterwards.
Which pedalboard do you have where this is most visible? I can run some tests here, thanks!
I was expecting it to stop showing up. I will try it again asap