I made a more simplified pedalboard for testing. This should make it clear that there is no one specific plug-in which is causing this issue. If you use the test tone with this pedalboard and then adjust the pitch, or volumes of the signal paths, you will eventually cause a situation where the CV does not work, and a gated signal is no longer gated. The sound of that happening is quite noticeable.
I use the pitch plug-in, but other plug-ins in it’s place will cause the same issue - so it’s not the plug-in being controlled by the device, it’s that “any” plug-in being adjusted could cause this failure. A simple volume adjustment is not CPU heavy, but it can fail when you adjust a volume using the knobs on the device.
I ‘think’ that this is a CPU spike of some kind. But it’s hard to tell.
i’ve been playing with everything you’ve got assigned to hardware controls on the Duo X, and i also assigned knobs on page 1 to the Test Tones Trim and Frequency… been jamming for almost an hour now and all the CV Gates are still working just fine.
indeed, i’m still seeing the kind of issues around meter displays which i reported earlier in the thread… whenever i’m turning an assigned hardware knob, the level changes which the gates are audibly making don’t show up in the Tiny Gain meters. further, though… an x42 Meter plugin placed at various points in the pedalboard (not just levels which should be affected by the CV gates) doesn’t update properly while a knob is being turned. however, if i change the same controls with a mouse in the GUI, the various meters do update during movement.
so it still seems to me that actual audio and control function is ok, but meter updating is compromised during usage of hardware knobs, when CV plugins are present.
there’s still quite a lot going on in this pedalboard; i think, if we’re going to isolate the issue enough to make a bug report, we need to simplify the board a lot.
ok, here’s a very simple pedalboard which shows the issue, as i see it:
on my Duo X, i see that when i adjust the Test Tones level using the hardware knob assigned to the Control to CV plugin, neither the CV meter nor the Tiny Gain meter updates properly while the knob is in motion. however, they do update during motion, if i move that knob with the mouse in the browser GUI. in both usage scenarios, the desired volume adjustment of the Test Tones is operating properly.
@S_Righteous can you confirm that you see this issue as well? …and does this correspond to what you’re trying to report? …i think it doesn’t, because you’re saying that you hear problems (i.e. it’s not just dysfunctional metering for you)?
@falkTX is this metering problem a known issue? if not, i’ll file a bug report.
[N.B. for testing, please turn on the LFO plugin in this board - i had to turn it off to get the screenshot to generate]
so, here we have a case in which the two meters show changes which are caused by a CV LFO. the lefthand Tiny Gain is assigned to a hardware knob. even though this plugin is not connected to anything and it has no involvement with any of the CV on the board, both meters stop updating when that Tiny Gain knob is adjusted via the hardware knob to which it is assigned. again, the meters seem to be fine when the plugin knob is adjusted directly in the GUI.
this behaves similarly on the Dwarf (if i assign that lefthand Tiny Gain knob to a Dwarf hardware knob), although on the Dwarf the meters also stop when that Tiny Gain knob is adjusted via the GUI.
First off, thanks again Plutek for testing this stuff out!
Indeed I have the same experience as you with both of your test pedalboards where the visuals do not update. And as you mentioned, I am also having a different issue which I believe is just CV + Device control overload.
You mentioned that with my test pedalboard you were not able to get that sequencer to crash and leave the gate in the open state. Right next to the pitch knob on the device, is the lowpass filter knob. Twist both those at the same time, and within a minute it will overload. The looper does not need to be used for this to happen. It is not a bug that happens every time, but happens eventually. I assume it’s just control overload.
My original pedalboard had unique processing on each of the 8 gated channels (you think this one was fun!) - so it overloads more frequently, with less effort. I have been running various melodic, vocal and random input into that one, and recording the results. Rapidly altering a value, or altering two values at the same time with the device knobs will cause it to crash. But even altering one value slightly ‘can’ cause it to crash eventually. For noise music this random crashing sounds fine, but yeah, it’s not intentional.
Here is an example using my more complex pedalboard so that the overload is obvious. I’m sending in some of my techno as the source, and have two loopers going through the same processing so that the signals organically affect each other in ways they wouldn’t if processed individually.
Due to the syncing of the gates, there is less ‘techno’ feel, which is intentional - most on the beat stuff is gated out by me using the sync button on the sequencer.
But with this source material, you can clearly hear where the CV signals just barf. With experimental stuff that result can admittedly sound good, but it’s not good for softer ambient where you may not want explosions of un-gated source loops.
ok… that clarifies things a bit; thanks for that sample, where it’s clear that the CV gating stops but then comes back. indeed, in your “simplified” pedalboard which you shared, if i twiddle the pitch and low-cut knobs for a while (or just one of them, actually, and other knobs too), i can hear that the CV gating stops – but then it recovers a second or so after the knob-twiddling stops, right?! interesting. weird. incidentally, i replaced Test Tones with Fractal noise - makes the CV gating more obvious to hear when other things are changing.
you know this already, i’m sure, but for completeness: i can’t trigger the CV malfunction by twiddling similar things with the mouse in the GUI.
one thing i have noticed: although the CPU load stays pretty constant around 62%, the RAM load does seem to creep up a bit each time the CV gates fail. and, in general, after a number of CV fails following wigglings of various knobs, if i just leave the pedalboard running for a while (some tens of minutes), the RAM load gradually climbs on its own. while the pedalboard usually loads at around 21% RAM, it often climbs gradually to ~70%, and once went to 100% and my Duo X locked up. have you ever seen that happen?
so it seems something is definitely going on related to machine load, but i’m guessing it’s gonna be torturous to pin down. have you tried gradually eliminating things in this pedalboard which might no be directly related to the problem, to see if you can get to a simpler demonstration of the issue? that’ll be key to debugging…
…unless, of course, @falkTX takes one look at these posts and goes, “oh, THAT!”
So I have never noticed the Ram load, only CPU. If it is climbing over time for no apparent reason, then that is indeed an issue beyond my assumption that CV + Physical controls will eventually overload if you use too many of them.
It’s interesting that the GUI changes would not cause this - I wonder if the dial adjustments on the device have to sync with CV in the GUI? no idea. But I don’t think I can adjust stuff in the GUI as fast as I can with the physical dials, and rapid changes seem to cause the issue more.
I have not had my DUO X lock up from any of these pedalboards, and I often keep my gear turned on for days at a time, but not processing a signal for days at a time. I wonder if the looper is somehow misusing Ram?
I do hope @falkTX has a look at this. And to be honest, if I have just found the CPU limit, then that is a reasonable conclusion. I know the device has limits - all gear does. I would just want to understand those limits better so I can try to work with them.
I would want to know the CPU hit of physical inputs, vs CV, vs CV going to more than one destination, etc. etc. I don’t think it’s the fact I’m using 8 CV signals, I think it’s some interaction between physical and CV control of the plug-ins. I have other way more complex pedalboards with more CV signals, but not with that sequencer. I’m grasping at straws here, but will do more testing. I will remove the looper first, you can still hear the issue with a live signal.
If the RAM usage is creeping up and causing issues, I suspect I have not simply hit some CV + Control limitation. There is hope yet!
I left my complex pedalboard running for four hours and it did not lock up my Mod Duo X. But I was not using the looper, just processing the test tone.
i only saw RAM numbers climbing during and after some episodes of making the CV gates fail; did you do that first, before the long run? my testing was also without using the looper.
One thing to be clear about - is that this behaviour where the GUI does not update is the result of either a Mod update, or Browser update - or some new change. I have older pedalboards which use CV control, and never had this issue, but now they have this issue.
I just tested where I removed the looper, and was able to get the CV to drop causing a gate to stay open. Then I also removed the sequencer and had midi coming into the unit from an external sequencer, and was also able to get CV to drop.
So this issue is unrelated to the looper, or the sequencer.
Even after getting the CV to drop, I have yet to notice the Ram % increase. So I will let it run overnight and see what happens.
I am more convinced that this is not an issue of CV overload.
Adjusting the pitch and lowpass using the knobs on the device will cause the CV to drop. But if I modulate both of those parameters with an LFO, moving faster than I can adjust the physical knobs - the issue does not happen.
The issue seems to be resolving/syncing physical input with CV input signals.
i only saw RAM numbers climbing during and after some episodes of making the CV gates fail; did you do that first, before the long run? my testing was also without using the looper.
I caused the pedalboard to fail twice, then left it to run overnight. The Ram % didn’t change much for me. So perhaps when the CV drops, or crashes, results may vary.
Hi Jon - I know you were not able to replicate the issues which Plutek and I have been documenting in this thread. What are the next steps? Does a bug report get filed? Is there something more I can do?
hey @S_Righteous is it important for you to run these pedalboards while connected to the GUI? …not saying there isn’t a bug, but i’ve been playing with various variations (trying to thin things out and get something really predictable and simpler), and whenever i have something which fails in a manner similar to your examples, it does NOT fail if i disconnect from the GUI.
my playing around with this stuff so far is leading me to the conclusion that the failure is very much correlated with the number of plugins which require realtime GUI updating.
take a look at this board:
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.
N.B. all variations of the board run just fine when disconnected from the GUI.
…i think we might be finally getting to something clear and simple enough to report… lemme know how it goes for you!
Along these lines, I found that plugins like the realtime audio level monitor and the frequency analysis graphs ate up significant CPU when the web GUI was connected. Again, these are realtime plugins and when not connected to the GUI, I didn’t experience xruns
I will try this pedalboard out. If the issue does not happen when the webgui is not connected, that is awesome news.
I very much do not think it’s related to the number of plug-ins or CPU usage, because I have pedalboards which use every knob and button on every page of the Mod Duo X, and which are way more complex, with a higher base CPU usage, and have not had any such issues.
Well no issues in the past.
I have pedalboards which used to function 100% fine, but now the Control to CV plug-in has this new issue we have been seeing. The number of plug-in in those pedalboards did not change, but they no longer work. I will test to see if they work without the webgui. But they certainly used to work with it.
Just tested your pedalboard, and indeed have the same experience as you. I had also removed the sequencer in one of my previous tests, so I knew that wasn’t an issue. I also tested my original pedalboard without the webgui connected and I wasn’t able to get it to crash. “rockin good news!”
Do you have older pedalboards which make use of the Control to CV plug-in and can you confirm that they used to work fine, but now do not?
