I’m noticing an issue with channel A of the Dual Looping Delay often not functioning. So far, I’d say that close to 50% of my patches that use a DLD have this issue. The way I prefer to use the DLD is audio going into input A and out of output A (therefore using both A and B delays simultaneously). So the problem is that often the audio just passes through channel A delay unaffected and into channel B delay (which does work). When channel A doesn’t work, there appears to be no way to get it to work again. Even deleting the module and replacing it doesn’t change it. Anyway, I was just curious if anyone else has noticed this or if anyone has any ideas.
Thanks!
…Oh, and yes, just to be clear, I’m aware of the normalizations between channels A and B. I’ve had the hardware module for many years and use it frequently in this same way without issue.
…one further thing I’ve noticed (and not sure if this is just coincidence) is that when I add the DLD to the patch first and set it up, it seems to work more frequently. But when it’s added later on in the patches development and setup, is when it often displays the problem with channel A.
One other detail (again, not sure if this is a contributing factor) is that my patches always have the DLD clocked internally with a virtual patch cable, but my A input and output are always real panel patch cables, as I’m using an audio source from outside of the meta module.
One final thing I forgot to mention was that all of my patches were built directly on the meta module itself. I don’t use a computer and don’t have vcv rack. Not sure if this makes a difference.
Something interesting I tried at least somewhat helped the situation. I again made a fresh patch- this time with 2 DLDs. The second DLD worked fine, but the first one had the broken A channel again. After messing around for a while, I went into the menu and randomized the controls on the first DLD and it seemed to somehow jumpstart channel A and it became useable. Not ideal, as then all the controls are randomized and need to be reset, but at least it got the module going which is great, because before, if I’d spent 20 minutes building a patch and then added the DLD and it didn’t work, I’d have to completely delete the patch and start from scratch (because as previously mentioned, deleting the DLD and creating a new one wouldn’t solve the issue for some reason).
At least this seems to be a kind of awkward workaround for now. Better than before anyway. I’ll try it again next time and see if it always works.
A little sidenote (sorry if I hijack the thread). But I want to mention, that DLD VCV rack version has an issue. It cuts the transient of the original sound being run into it. So if I run a sound through it but keep it 100% dry, then the attack portion of the sound is missing. Haven’t had time yet to see if this issue also occur in the MM version.
Sorry I missed this post. I have some ideas what it could be. A few clues like it mattering what’s the order of the modules being added, and deleting and then adding the module not helping are ringing a bell with some other issues I’ve found. Hmm… I’ll see what I can dig up.
There’s an option for “AutoMute” for the A and B sides: it’s in the right-click menu on VCV, and toward the bottom of the controls list in MM. Try disabling that and see if you get the same transient issue. It might be that the level at which to cut-off the audio needs adjusting on the virtual version. I thought we set it to match hardware but listening to it now, it seems more intense than on hardware. Let me know if that’s the issue you’re hearing.
Hi, not sure if you’re wanting a video from me or the other person in this thread, but I just quickly made a short vid with my phone. Nothing special, I just created a new patch on meta and put a DLD into it, hooked up a manual gate button module to the ping input and you can see that the clock is working for channel B but not channel A. Then I randomize the controls in the menu (I then have to push the button a few times to set the ping/clock again) and you can see that now the delay A is also working. I made the vid super fast, so didn’t hook up any audio or anything, but when audio is hooked up, channel A delay does not work. It passes it to channel B which works as expected, but channel A has no effect until randomizing controls somehow jump starts it. I would say this issue happens at least 25 percent of the time for me, if not more. Right now I’m using the beta firmware, but this issue was also present on the regular firmware too.
OK! I found the bug that was causing the channels (usually channel A) to sometimes get into a state where they won’t clock, and another bug that made the LEDs look erratic when using an external clock into Ping.
I’m wrapping up an update to the v1.6 branch, and I’ll put this in it.