Avoiding clicks with circular buffers being continuously read and written
Hi everyone! I have lately discovered the [snowphasor~] and [snowfall~] objects and I had a lot of fun using them to create a pseudo-granular delay using [groove~] and a continuous buffer:
(the patch uses [ipoke~], but if you don't have it you can just use a normal [poke~] to get a functional version).
The buffer gets (i)poke~'d continuously while the playheads of the multichannel groove are independent: this means that whenever the playhead crosses the point that is being written a click arises.
Using [ipoke~] with a certain dose of overdubbing I managed to get a marginally better result... But does anyone else know any more effective method? I would like to keep using [groove~] for its timestretching capabilites and therefore using a simple delay line is unfortunately not viable.
Thank you in advance!
hi, this is an advanced issue which is too lengthy to work out in full, but at the heart is a simpler idea which you can keep in mind as you experiment and research further on your own:
-i can't remember if ipoke has a signal-accurate way to track its position, but esssentially, you need a signal-accurate tracking of both the 'read' and 'write' positions, and whenever these positions come within a 'threshold of proximity'(a certain distance determined by both the speed of their travel, as well as the time needed to fade/crossfade), you can either 'duck' out the volume of the record-head temporarily(or duck-out the volume of the playhead, but this is more noticeable in sound right away), or crossfade the recording-head into a separate buffer where it can write information temporarily until the playhead has passed by(then copy that information back into the main buffer with appropriate crossfade, etc. after it is safe to do so)
all of this is a bit technical to work out because the distance between them can change more rapidly depending on the speed of their travel, therefore, the sound of the crossfade can differ widely depending on context if you're not careful to incorporate the different parameters carefully when calculating it.
for starters, just track the two positions, establish a running comparison(subtract one from the other, and use the absolute value: when the absolute value is below a certain amount, begin a fade-out of the playhead to have it automatically fade back in at a certain point; basically just a 'ducking' mechanism to duck out the volume of the playhead)... if you can get this much, you'll be able to work out the more advanced ways. you do have to incorporate both speed and direction of travel, though: two objects traveling at close to the same speed but going in opposite directions will interact with each other more rapidly than two objects traveling at close to the same speed but going in the same direction(you don't want a fade which is too short to do anything, but you also don't want a fade which can take forever to complete).
hope this can help 🍻
Hi! Thank you so much for this detailed explanation, it is really a gold mine.
It had occurred to me that ducking could be the solution but I couldn't work out how to actually implement it. Tracking the position of the read head and the write head makes absolutely sense as they are both driven by a phasor! I will try triggering a mc.line~ down-mc.line~ up on the mc.groove~ (it sounds like the easiest option). The only problem, using mc.snowphasor~, is that the ramp time of each instance of a phasor is a stochastic process, so I should try a way to get the derivative of each ramp so to correctly "arm" the mc.line~... But I will need to get my head around it.
Again, thanks for the precious intuition! ❤️