Reverse Delay - first module prototype

Would love to hear your guitar through this module patch, is there audio or even the patch available? Life treating you kind?

1 Like

Yep all good @ady34. As always, I went off on a total tangent and went a bit over the top, so the patch that started with a few reverse delays somehow ended up with 16 Chronoblobs using the send/return loop, but with feedback loops going into a merge and then through a polyphonic flanger and a filter. After that, it wasn’t really demonstrating Dan’s module because the reverse delays were feeding into a load of madness, so I haven’t posted it anywhere. :joy: Incidentally, with polyphony I don’t need to create these crazy patches with tons of modules, but sadly Chronoblob isn’t poly yet and I couldn’t find a poly delay with send/return loops. There’s an idea for you Dan!

1 Like

Thanks @alefnull,I really appreciate that!

1 Like

For delay send/return loops try the Venom Modules Recurse (Comes in mono and stereo versions). Does that do what you need? It’s polyphonic to boot…

1 Like

I started to dig into the Marbles clock input to figure out why it’s so much better than all the others, and I found it, holy crap, this is lovely.

I’d been mentally designing a better clock input for the past couple of days, just in my own head, and this is like leapfrogging a bunch of problems I was wrestling with, mainly that I could imagine several approaches and what if one was better than another for a given situation? Check out this explanatory comment from Emilie Gillet’s ramp_extractor.h: https://github.com/pichenettes/eurorack/blob/master/marbles/ramp/ramp_extractor.h

That’s beautiful. That solves so many problems. Basically I was trying to figure out how to deal with a clock that is wrong sometimes, and wanting to figure out which of the clock pulses were the ‘right one’, this is exactly the way. Use different ways of guessing to predict the next edge, and stick with which ever predictor is right more often than any of the others, and I think that will give a much steadier clock pulse that can also be changed relatively quickly, but also won’t slew around all the time if the clock generator pulse is a little unreliable.

It’s just so brilliant and beautiful, and such a subtle paradigm shift.

Seems like a great example of where clock-phase instead of clock-pulses could solve a lot of gnarly problems with detection logic and so on. Much simpler. We talked about it here:

In thinking about it again, I would propose the phase-signal to be a saw-wave, so sharp leading edge (falling ramp) because you would get the trigger signal from the leading edge for free.

2 Likes

Ah, thanks so much Lars! I’d seen some of those standards discussions when searching, but hadn’t read this one!

In looking at Marbles, I was specifically thinking of some of my experiences trying to get Impromptu’s clock to sync to an external FH-2 from Expert Sleepers. I had a really good experience syncing Clocked to the FH-2 using the P24 setting. But I had less good experience using slower clock inputs and getting a solid sync.

At that time I was thinking I should sync all my external equipment to FH-2, and send the P24 clock into my computer to sync VCV, and I’d only have half round-trip latency that way.

But, my Marbles module is so good at syncing to even slow clock signals that I gradually switched to using it as my ‘main clock’ externally, and I offset the roundtrip latency in VCV with a scope and a loopback cable and a second Clocked module.

This looks like:

So I thought, Marbles is doing some kind of clever clock recovery magic.

But, within VCV, Clocked is rock solid. It’s only when I introduce external clock signals that it gets wobbly at the lower pulse per quarter note levels.

Anyway, I need to do some more careful reading of that post before commenting further, but that was my thought process before now.

Yeah, jitter, it’s the worst thing and pure poison for clock/tempo detection logic, and it seems like Marbles is good at handling it, but it’s also pretty complicated logic as can be seen. Clock-phase would not solve that, it would just pass on the jitter as it’s just a “varying clock speed”. For smoothening out jitter I don’t think there’s any way around complex logic.

However, in a “perfect world” all you need is BPM-CV and clock-phase. We just need to get all the hardware vendors on board :slight_smile:

1 Like

That’s my feeling as well, I was pretty surprised by how hard good-sync was to obtain, and yet how well Marbles did it.

I’m going to give it a try to just import the Marbles code rather than rewrite it, and try to make it work for clock sync on this module. If it works, that will be a good excuse for me to make the code public so other people can use it as, hopefully, a drop-in clock recovery device.

I’m a better C programmer than C++, but I feel like this is a good excuse to tackle some object orientation.

Haha, yeah, I think VCV Rack comes as close to a perfect world for hardware ideas as I’ve ever seen! But I’ve lived for too long in the other hardware world, I can’t put both feet in one or the other now it seems :slight_smile:

1 Like

Definately give it a try. You might run into some 8V and 5V levels in Marbles that really should be adapted to Rack standards but otherwise - great if it works! Would be very worthwhile as a stand-alone “clock-detection” module! And yeah, the “standards” and levels in Eurorack land are pure anarchy compared to the sensible voltage standards in VCV Rack. A few, simple standards goes an awful long way…

1 Like

Haha, very true. I admire the work of standards makers, it seems like such boring bureaucratic work, and yet they have clearly made the world a tangibly better place and all of our lives so much easier and better-off.

Still can’t help but think about that old joke, ‘You know the great thing about standards? It’s that there are so many of them to choose from!’

Makes me laugh to myself and groan internally as well :slight_smile: It’s as painful as a good pun!

1 Like

BTW, if you’re into that kind of thing I can’t help the instinct that there’s some gold to mine here by looking at phase locked loops for this kind of problem.

2 Likes

I haven’t tried it out, but the RPJ Circular Ride looks like it can give Chronoblob a run for its money, and it is polyphonic.

Also this one is polyphonic, and stereo:

Thanks, saw the announcement on Dave’s modules but haven’t tried them yet!

CircularRide is great, but doesn’t have a send/return loop, and neither does Surge XT Tuned Delay. The regular Surge delay isn’t poly either (yet).

Cheers

the AS delay has a send/return loop
both the mono and stereo version, tho they are not polyphonic

1 Like

I finally read the Chronoblob documentation, and now I understand what Send/Return you are referring to. Now I understand why those blue modes never did much for me!

My Venom Recurse will definitely not help in your use case. It recursively sends/returns a signal to/from a polyphonic module, with each pass going through a different channel. The signal never gets mixed, so it is not feedback.

You want output fed back and mixed with the incoming signal, with the option of inserting additional modules in the feedback path, all on the same channel. (Actually you want a polyphonic version of that feature, each channel with its own feedback loop). I can see how that would be a great feature.

1 Like

Yep, there isn’t a poly delay with feedback loop yet. It’s fine, I can just use 16 Chronoblobs with the sends into a merge, it’s the same thing but poly patching is just easier and looks neater! Effects in the feedback loop are great fun, particularly frequency shifters, Clouds and modulation.

1 Like

My first handmade hardware synth had a one or two defeatable PLLs in it, I would would generate different frequency signals and then cross connect them using a repurposed multimeter knob that could short different connections together. And then I would power starve the circuitry so the PLL would have different clock recovery rates. It was quite fun, the PLL gave it a real sense of life and responsiveness.

2 Likes