Thanks, that’s super helpful! So are there any plans to support a CPU upgrade yet, or is it just an idea at this stage? It would be awesome to be able to do that 
1 Like
GPU ?!?!?
Is there a GPU on the mod ?
There is a built-in GPU in the processor.
Wow ! That is interesting to know !
So I was noodling around tonight with my MOD and found an interesting way to run my the Drop pedal at high fi without having to give up other effects…(maybe everybody else already knows about this?)
I can plug in to input 1 and first effect is a switch that sends the signal either through my standard effect chain (OD, Distortion, Chorus, phaser, EQ, Compressor) that exits at output 1, or it gets sent to a Drop pedal at -12 in high fidelity which then exits output 2. I then have output 2 directly connect back to input 2 and then that runs through the previously noted effects loop and it works just fine!?!?
Is it because once the shifted pitch leaves the MOD then it doesn’t have to be treated like an effect anymore when it comes back in through another input? I am honestly amazed at this, I may be able to rid my pedalboard of my POG2 due to this.
Is there a way to program the MOD “pretend” that the pitch altering pedals aren’t “effects” as soon as the signal leaves those plugins? I know nothing of programming! I’m totally fine with just using the wrap around solution I just figured out, but I’d love to get a free second output back!
1 Like
Cool discovery! The Duo signal routing flexibility is a unique and powerful aspect of the device.
I’m not sure I quite follow what you mean here, but here is my understanding of the technical process. The MOD (as a whole) and the individual plugins themselves have no ‘knowledge’ about what state a signal is in. If there is a signal, it will be processed and passed on through each step of the pipeline. In the case, where you have the switch going to your Drop, the overall signal pathway will look like:
* MOD Input 1
* ADC (audio to digital converter)
* Pedalboard input 1
* Drop
* Pedalboard Output 2
* DAC
* MOD Output 2
* MOD Input 2
* ADC
* Pedalboard input 2
* Effects chain
* Pedalboard output 1
* DAC
* MOD Output 1
In the case where the switch is routing to the Drop, you are doing two passes on the audio signal. This will introduce some additional latency compared to the case where your switch is passing directly to the effects chain. For many users or use cases this is fine, though some performers or listeners might perceive a difference.
Is the reason you don’t route the Drop directly into the effects chain due to CPU? The MOD has a setting for doubling the frame buffer size, meaning you get double the processing time at a cost of double the latency. It might allow you to handle both routes in one pass without having to do the loop around externally.
1 Like
Hey unbracketed,
Yes, I’m running the Drop (Hi-Fi) in wrap-around since this oddly works within CPU usage, when running it directly in the effects line draws the full 100 in CPU.
My main question is…why does routing the Drop effect via wrap-around save so much CPU?
Also, I guess I’ll get some latency if I do the wrap-around or doubling the frame latency, but I barely notice it doing the wrap-around. shrug
You haven’t saved any CPU, you are spreading the processing out over more time by doing two passes.
Maybe this will help - imagine instead you have 2 Duos. One is running your effects chain pedalboard. The other is running the Drop. Instead of the plugin switch you have a physical switch that routes between two Duos. Switch out 1 goes to effects Duo. Switch out 2 goes to the Drop Duo. The Drop duo out goes to the effects Duo in 2. This should be an equivalent setup to what you have. When you set the switch to go to the Drop Duo, the amount of CPU consumed will be the sum of the two Duos. It will take twice as long to go through this path, since there is an additional Duo handling data.
Taking this further, imagine you split your effects chain into dedicated Duos per effect (each Duo runs a single effect). Each Duo could be expected to have pretty low CPU use, at a tradeoff of the overhead of converting the signal in each Duo. If you string together several Duos, each one might run efficiently, but each Duo is adding a conversion overhead. There’s nothing free, and there’s no magic here. The good news for you is that for your use, the additional latency of your solution isn’t causing problems (as you report). But the laws of physics and DSP are all still intact
3 Likes
I think by not having the dropped signal recombine on the pedalboard the processor can split the signal into 2 paths and spread them into 2 cores more easily. When the signals combine again then suddenly it has to go to the same core for the last few plugins and it might not be able to use multiple cores at all. I’m not sure about how it decides what to do in parallel, but I’m pretty sure a linear graph will always be on a single core.
The Yankee power supplies from Poland look like they’ll do the trick.
1 Like
My 1Spot Pro CS6 is working out just fine so far for powering the Duo plus foot switch, EHX NanoPog, and EDB Headway 2 (which I just replaced with a Tonedexter).
1 Like
I’m having great luck with the CS12 powering the duo, a shure wireless receiver, a sonic research tuner, and a wah.
I just wound up using the original power adapter with a surge protected power strip. I plugged in my HD500 and Helix FX into it as well and it’s fine so far…
is the power requirement for the Duo X the same as for the Duo?
Yes, you can even use the same power supply
2 Likes
That’s right, the power rating is exactly the same. the DuoX is a lot more powerful, but luckily also more efficient 
4 Likes
Does the Dwarf require less power than the Duo and Duo x? Trying to workout power for it also, and wondering if I can get away with 900 miliamperes? (2x450ma outputs on a Vitoos ad10-sv4) Is there a measured reading of how much current the dwarf draws?
1 Like
All the devices are the same for the recommended power supply.
Check more here: Dwarf User Guide - MOD Wiki
1 Like