I had them fully ccw in the video–that seemed the easiest way to get them to be the same when using the slew to control the amount. It works better to attenuate the modulation inputs more when using them to control the amount though. It seems to work fine even if I can’t get the attenuators to be exactly synced.
That’s an interesting idea about randomizing the rate, I’ll have to test that out when I get back to my rack.
that’s such a fantastic patch, thank you and please post more if you have more!
… and instead of the 2 vca´s (to do the crossfade between both delay channels) try a lpg. I just had a lot of fun with my natural gate wich I triggered with batumis square out´s. sounds better to me, specially when you go down to lfo rate. 
I also used two invert/slew cicuits to bend the ramp that is fed into d0´s. happy times for more variation of the pitch cv.
Um… I have a design for a preset recall module. I thought I mentioned that. It’s very simple as said above.
I was just waiting for more input on the functionality as I am a new (and maybe short lived) Mungo user.
The idea so far is to have 4-6 16 pin power connectors on the back, each with the pin dedicated to MIDI going to their own tx line on a Teensy 4.0. This would isolate the zoom/select bus “mis-use” from the rest of your CV/gate lines in the system, as the module would distribute power and just have one power cord coming in…
From there its a matter of what should be voltage controlled and how complex or often these presets are going to be saved and recalled…
My idea as it is now is that the Teensy will store objects for “meta presets” like [ch 1: pgm 13, ch 2: pgm 44, ch 3: pgm 88, ch 4: pgm 1]
As far as the interface goes I thought one 3-4 char 7 seg led display with an encoder to select a meta preset and one display that you could go through the 4-6 composite programs that make up the meta, as well as load and save individually…
Again, I’ve verified the details with John and have a kicad file underway… I’m just clueless as to what people want for an interface, and being new to Mungo I am a bit naive as to more advanced users workflow.
Does anyone know kicad, would anyone collab on the hardware or the firmware? This really would be rather straight forward once an interface was agreed on.
Mungo modules are notoriously picky when it comes to power, and they draw quite a lot. Wondering if extending/bundling them in such a way via ribbon cables might cause problems, especially in regard to the 0V reference?
Interesting. Can you elaborate? I think I get what you’re getting at… some intermediate gnd? could more/thicker cables be used?
I am not an expert, however I did have problems with power in the past, especially with my d0, which did go away once I started using Hinton power and distribution. So, let me quote Graham to elaborate. 
In any unbalanced system (and some non-transformer balanced systems) there has to be a common signal reference. Calling this Ground is confusing, so call it Signal Common or Common or simply 0V to differentiate it from other grounds. To keep the 0V voltages in each module at a similar potential the resistance between them has to be very low. With busbar distribution this is limited to the sum of two module cables anywhere in a system.
While it’s a product description, there is good info in the text the quote is taken from: HINTON INSTRUMENTS: Power Distribution
Graham goes in depth about this in some huge threads on MW which I can dig up if you are interested.
You could just make a handful of custom cables which divert the CV/Gate bus pins to a separate header and avoid having to be responsible for power distribution.
Yes, but then you are putting high frequency digital signals into your entire power distribution…
Which is something I’ve seen Sir Graham Hinton go off about on other forums too…
What if you ran one or two cables such as these 22AWG to the module?
On some physics table I see that the “resistance per 1000 ft” of 22 awg is 16 Ohms vs 64 Ohms of 28 awg (typical idc).
…and then just keep the power traces really broad on the pcb?
I’m no expert either, and I don’t think any of my test equipment will measure sensitivities such as these…
The MIDI end of the cable would go to your expander, power end to case power bus. Isolation would be equivalent to normal front panel patching (ignoring coupling within the ribbon, which is minimal for these currents).
Ah, I see that I misunderstood your drawing. Thanks!
If there isn’t shrouded connections one could probably use common 0.1" jumper wires for that too.
Just have to get one wire over…
The power distribution thing is a reaction to this…
Do people wantvto have to worry about special cables or be covered with typical/conventional equipment?
I’d definitely go the route of breaking out the MIDI signals and wiring them individually, either using custom ribbons or jumper wires. Power straight to distribution from each module, no duplication of bus cable lengths, no additional connectors, and no bottleneck of having one bus cable carry heavy load from all modules. I don’t think thick wires will resolve potential problems, Graham still considers his custom bus cables to be the weakest point of the distribution.
There is another aspect, I remember John stressing in some thread on MW that the single most important aspect of powering (Mungo) modules is to not overload the PSU, and that most PSUs are rated optimistically. So he’d never max out the available current but leave plenty headroom. Since d-series modules draw a lot of power, I think it’s beneficial to have the flexibility of connecting them to separate PSUs in a large system, which wouldn’t be possible if they get power from the preset manager.
