GUI stalling and CV failure - Duo X (possibly also Dwarf?)

GUI elements stall and CV fails with hardware knob control

Reporting two issues together, because I believe they are related…

  1. When a plugin parameter is mapped to a hardware knob, any realtime-updating GUI elements (i.e. especially meters) stall.

  2. 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.

How to reproduce

  1. load this pedalboard
  2. enable the meter plugin.
  3. twiddle the hardware knob which controls the volume.
  4. observe that the meter plugin stalls while the knob is being moved.
  5. load this other pedalboard
  6. start the transport rolling (leftmost Duo X button) - that gets the sequencer running, which toggles the switch via CV, producing an intermittent output tone.
  7. 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.
  8. the CV gate will fail in about 5 seconds.
  9. 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.
  10. 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.

There is a thread in the forum about these sorts of observations:

…between the two of us who have confirmed these issues (@S_Righteous and me), we have one production-run Duo X and one Duo X LE.

Open the controller menu (hold left knob down), navigate to Info > Versions and write down here the version.

  • release: 1.13.1

Also provide some information about your system if possible.

  • Operating system: macOS
  • System version: Monterey 12.6
    (those system stats are for me, with the DuoX LE)

I’m testing this now and…

I can’t replicate this :confused:

If I didn’t well, nop as well…

all good as well.

Then I updated the device that I was trying on to the 1.13

And then I had the behavior that you are describing on the first pedalboard.
The second one either didn’t notice it or I didn’t understand the issue.

@falkTX is it possible that this is a 1.13 bug?


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 :expressionless: I was expecting it to stop showing up. I will try it again asap

EDIT: actually @Steven_VE already confirm the bug




1 Like

Good to hear the bug has been confirmed!


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 was able to reproduce so eventually a fix is coming.
This is a tricky one that involves going quite deep in the stack, will take a bit.

All the investigation for it is very nice and appreciated!


@plutek this should be fixed with Release 1.13.2
confirmation would be quite welcome, thanks


thanks a lot, @falkTX … yes, it looks fine here now!

@S_Righteous can you please test this as well, including some of your other pedalboards which were related to this problem?

Yes of course, I’m eager to do so.
I was born to break things!



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.

1 Like

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!

Just to confirm, you want to test the pedalboard which was open when I tried to load a new one, the new one probably wasn’t the issue, right?

well any to which you refer:

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.

when you mention the “very simple pedalboard”, is it this one? meter_stall - MOD Audio

This is the simple one I was loading:

But the one which was loaded, was this one: