Input crosstalk - DuoX


surprisingly high crosstalk between inputs on DuoX

How to reproduce

  1. connect any input source to only one input
  2. adjust levels such that input is peaking higher than about -7dB
  3. you will see the LED level indicator on the other input channel begin to light up
  4. if you patch a separate meter plugin on each input, you’ll see that there is, indeed, signal on the unconnected input, and that it measures about 33dB down from the active input. (behaviour is the same using either input)

Expected/suggested solution

i would not expect to have such noticeable leakage between inputs - i.e. we shouldn’t see meter activity on an unconnected input

Additional information

i don’t remember encountering this on previous MOD system revisions…


  • release: 1.10.0
  • controller:09DBC77


  • Operating system: macOS
  • System version: Big Sur 11.3.1

Thanks for your report.
There’s some known cross-talk issue between the inputs on the DuoX that we are trying to find a nice way to minimize.
Now, my question is: are you sure that you didn’t have this on previous firmware versions? Are you somehow able/willing to downgrade and double-check it?

i just checked 1.9, which behaves the same way.

then i checked 1.7, which is from around when i was doing a bunch of studio work with the DuoX and didn’t notice the issue. it is actually behaving the same way, in terms of the level of signal leakage and how that measures with the meter plugins. it just doesn’t show up on the LED input indicators, because of the different sensitivities and colors which were used in those indicators at the time. on that version, the second input LED doesn’t begin to light until the input with the signal is flashing red.

so, in short: the issue looks like it did always exist, across many software revisions. probably a hardware issue?

as a side note: i do prefer the current LED sensitivity, since it shows a much lower level of signal.


I also found this cross-talk when trying to use 2 separate input signals to process and had reported it to the team (couple months ago already).

Hope we can find a (relatively easy) solution for this, as it means you can’t process individual inputs at all.

1 Like

As you said @dreamer, we are aware of the issue.
Answering to you and also @plutek, we are still investigating for solutions. It’s taking a bit longer because of the amount of work that we currently have in our hands and all the constrains to get it done that we are having.

1 Like

I’ve been using the Mod Duo X as a dual mono processor and have just now noticed the level of cross talk in the inputs. I went into settings and unchecked the stereo link, but clearly that has no effect. I had thought there might be a setting in there to really separate those inputs.

I’m just curious if this is a hardware issue which cannot be solved via software, or if you are able to implement a setting which makes it true two channel mono?

Not sure where this is on the massive list of things to do.


I believe this is an hardware issue.
It may be fixed/improved with more carefully set gain staging (if possible in your setup), I believe.

1 Like

I figured it might be hardware. Thankfully at the moment I don’t need to run both channels at once, so I have a button set up to toggle each channel being muted. This works.

1 Like

May I ask which two instruments you are using @S_Righteous?

1 Like

In this particular case, I’m using the Mod as a processor for live use, so one channel is getting a vocoder signal, and the other is getting a radio signal.

Then I have hands-on control of delays, reverb, and a bunch of signal mulching/slicing/ for the radio signal. The radio is loud, and was leaking into the vocal channel, and that’s not ideal, but I have a button toggle set up, with the CV stuff so only one channel is un-muted at a time.

Having the radio mulched up while doing vocals actually sounds good, but I’m building this one step at a time.


Since the v1.12, the DuoX now also has a noise gate and compressor which apparently solves the problem after the first test.


Hmm, I wouldn’t say “solve”, but it prevents a “competing” signal from interfering too hard when the other one isn’t playing. So it somewhat mitigates the issue but doesn’t resolve it.

The cross-talk is still there and can still cause unwanted side-effects and extra “noise” in the signal chain.

Lets call it a band-aid solution :wink: