4ms DLD not behaving correctly

Plugins
1

or perhaps there are just inherent differences between the hardware version and the mm version that aren’t documented? i don’t personally own the hardware module but i’ve been attempting a scour-through in the manual to try and fully tame this beast for vcv/mm. im finding that the manual doesn’t explain things for the vcv/mm version, among a few other oddities.

buffer clearing:

  • the manual states “holding down Reverse and Infinite Hold for two
    seconds. The sound will cut out briefly while the memory is cleared” - ive tried mapping one mm knob to all the reverse+hold buttons on a single instance of the DLD and both in vcv and on the mm, the buffer doesn’t seem to be cleared when i turn all these buttons on and wait. am i perhaps just doing something wrong?

16-bit mode/longer delay times:

  • manual states: “Almost 3 minutes of time per channel (2:54) in 16-bit mode, for a total of nearly 6 minutes” - how do we access this 16-bit mode/longer delay times? i can only seem to get about 1:28 when sending a very slow clock into DLD, the time knobs all the way up, and the +16 switch engaged. i’ve looked in the alt params menu and have tried turning on/off the various options but none seem to engage any sort of longer delay times.

mapping mm knobs to reverse or hold button has confusing behavior:

  • i have to turn the mm knob all the way up 100% then all the way back down to 0% to turn on either the hold or reverse buttons. shouldn’t it be when the mm knob is at 100% the reverse button turns on/lights up… then when the mm knob is at 0% the reverse button turns off? again i tried the alt params but none seemed to affect the behavior of the reverse/hold buttons

saving tap tempo ping time within the patch:

  • the manual mentions “In order to keep your Tap Tempo Ping time, depress any of the four lower buttons before pressing the Ping button” - this doesn’t seem to work with the vcv/mm version. when i reopen the .vcv patch, the ping reverts back to it’s default speed. or perhaps am i just doing something wrong? would be nice to have that manual ping time somehow saved within the vcv patch/restored on reopen.

“stereo mode a/b” alt parameter:

  • what do these pertain to in the manual? im not finding anything off the bat that correlates.

maybe @danngreen or some others who have used the DLD in vcv/mm more heavily could help fill in the blanks to better understand the unique behaviors of this amazing module? tia!

2

I don’t know if any of the hardware module’s button combos translate to the virtual version.

Switching between 16 and 24 bit is done with a jumper on the PCB, so that’s probably out the question :wink:

The module is one of my must haves, how can anyone not own it?!?

3

yeah its a beast! with tons of options via the send/return or patching output a into input b (curious if doing that is correlative to the stereo mode a/b in the alt params in vcv?). id really love to understand it fully though.

re: 16bit extra long mode, dan mentioned it a while back in this github thread so im hoping there’s a way i can access it in the vcv/mm version:

Dan=“Re: long delays… have you tried the DLD? It has two channels with up to 3 minutes each.”

maybe it would need to be enabled as one of the right-click alt-params of the module. dunno.

4

So, the virtual DLD is actually the firmware for two Looping Delay units. We did this because the LD has the stereo feature and the code had be re-written more recently in C++ so it was easier to port.

Here’s the manual:

So on the LD, the memory clear is done by holding down the Ping, Rev and Hold buttons, and keeping them all down.
It actually works on the virtual DLD, but the problem is the act of clearing the memory is a CPU spike and the patch stops. On the hardware version you just hear an audio glitch – but on the virtual version it spikes the CPU and the patch stops.
It’ll act more like hardware when the feature to allow CPU > 100% temporarily is merged in. Clearing the memory buffer is meant to be an intensely harsh operation – sort of like a Panic button. Normally you would just set Feedback down and let it fade out.

The total delay time for and LD (which is each side of the virtual DLD) is 87 seconds in mono mode and 43 seconds in stereo mode. The delay buffer is 8MB per side, so 16MB per virtual DLD module.
The hardware DLD has twice that memory (and only functions in mono mode), hence 2:54 = 174 seconds.
I don’t think there’s a reason we can’t make the virtual DLD have the same time as the hardware DLD — module loading time will be longer since it has to clear the buffer, and also of course memory usage will be higher (approx 12% of total memory used).

Another difference: 16-bit mode is always enabled for the LD, and hence the virtual DLD. Making this an option would be more complicated – it can’t change while the module is running, but it could have an AltParam for the mode you want it to start in the next time you load the patch. So if you set this in VCV, then when you loaded it in MM it would be right. But if you changed in it MM then it would have no effect until you reloaded the patch.

If you map a button to a knob, you can just turn the knob a little to the right of center to “press” it, and then turn it back to a little left of center to “release” it. But, yeah, mapping buttons to knobs in general can be done in one of two ways: 0 = off 1 = on; or 0->1 = toggle. The virtual DLD does the latter.
With the button expander, it works naturally: tap a button and the Reverse toggle state, just like it does on hardware.

If you needed a knob to control Rev or Hold like you said (knob down = off, knob up = on) then you could map the knob to an Atvert2 or DualAtenuverter or something, and feed the output into the Rev/Hold trig jack. Then set the AltParam for that jack to Gate.

The button combo doesn’t apply to the virtual DLD, but it should save your ping time when going from VCV to the MM. I just tried saving a simple patch with two DLDs, each one tapped with a different tempo, and then I loaded it onto the MM. I ran my VCV audio output to a (hardware) scope and also the MM’s DLD clock outputs and compared. The clock outs for VCV and MM match exactly.

Ah, yes, that’s only in the LD!

5

Ooops! Sorry, I mis-spoke on that github thread. I forgot the virtual DLD is two LD’s = two channels with up to 1:27 each.

6

ah ok! that certainly explains things. also ty for LD manual link.

the issue im noticing is that the dld isn’t saving very slow ping times in the patch. we need those slow ping times to access up to the 87sec limit. it seems to save up to around 1.75sec ping time (i.e. ping button flashes every 1.75s) which gives only about 56 seconds delay (w time knob at 100%, switch at +16).

so for example: i create a new vcv patch with dld, and manually click the ping button very slowly, i can then access up to that 87sec delay time. but when i save the .yml and load it on the mm, it reverts back to that 1.75sec max ping button time so i lose access to the 87sec delay time. this is also the case if i reload the .vcv file- the ping button no longer flashes slowly but instead flashes around 1.75s. is this correct behavior or perhaps a bug?

or most likely im just not doing something correctly…

sounds good! looking forward to this CPU > 100% feature. i think using the delay heavily in a performance situation, often is useful to kill the delay buffer quickly to start filling it in again to keep things moving sonically. as opposed to pulling the fdbk all the way down and having to potentially wait up to 87sec

that would certainly be useful- for many creative and live situations.

perfect, great idea- thank you for mentioning!