Not sure I understand, where do you do the switch? And why do you want to switch if you know that a node is only processing a single channel?

If you're node is known to be mono, then just process the first channel in the implementation, or if you want to force a generic node to only process the first channel, you can use the wrap::fix template to force mono processing.

// instead of this member declaration MyClass obj; // use wrap::fix<1, MyClass> obj;

Your code is probably throwing an assertion at auto* right = block.getChannelPointer(1); if you have created the audio block from a single channel process data object.

@Orvillain
There is an audio render snippet in the snippet browser. Maybe you can build your own exporter based on that?

@griffinboy said in Ring Buffer design:

@Orvillain

I've never used sync / fir interpolators in a reverb.
I'm not sure how high the benefit would be.
For delays and synthesis it's great though when you need low aliasing and low ripple.

A typical approach to decorrelating reverbs is to mildly modulate delay times in the FDN. But you can also do it on the input diffuser or the early reflections APF network too. So anything that affects delay time is ultimately going to make some kind of difference.

It'd be interesting to compare them all. Maybe that's a new thread in a few weeks or so!

@griffinboy Oh nice!! Some night time reading material right there!

@Christoph-Hart Ah nice! Yeah that gives me a similar result to what I posted above, just with less faffing around I suppose!

@Orvillain yeah that‘s just a glitch of the popup interface of the editor and I never looked at one long enough to bother fixing it.

Just to report back, it worked perfectly. It even now picks up the lastest value properly, whereas I'm pretty sure it didn't before. Very nice!

So here's my take on how to do switchable LFO's:

You primarily rely on the built in modules monophonic/polyphonic flag for reset/retrigger behaviour. Don't bother even building it for your own network.

Do your sync this way:
0bc0eeef-5d7a-4c85-822a-a9b901fc0519-image.png

A branch container, containing two chains. Each one has its own ramp source in it. Make one of them the regular ramp source, the other one the clock_ramp source.

You can even write a simple math expression to adjust the phase.

@Christoph-Hart Yep, that has fixed it, thanks!!

@Christoph-Hart Yep, this is fixed now. Thanks Christoph!

@DanH I think spread can be achieved by adding a split container after this "mono" phaser... and letting the signal through in the left half of the split (just add a gain there) and in the right... add a delay, and set the delay time to sub 20ms.

That'd be a nasty way to do it anyway!

I'm just now learning how to use the clone stuff, so there may be a better way.

@DanH Yesterday! 😂

@d-healey Yeah, I think I can essentially boil down 11 functions down to 3 functions with this. Pretty cool, cheers!

@Christoph-Hart The more things change, the more things stay the same! 😂

@d-healey Probably a bug of some kind then. All I can say is, commenting out TreeBuilder.buildModuleLayout() cured my crash. Chased my own tail for a bit over that is all!

Thank you guys! Lot of stuff to look into here! Appreciate the help. Will report back!

@Orvillain build your own..use the playhead data to define where you are in the seq...

@Orvillain
Oh ok, my bad then. Maybe it’s your sample that’s below 0dB, so it goes up and then drops back down. Anyway, glad it’s working for you now! 😊

@Lurch Cheers dude! I'll check it out!

@Orvillain ditch the smoothed parameter, you don't need that with the fix_delay node, then it should work (the smoothing is already embedded into the node itself).