Groove~ Start point audible clicks, ideas
Hello everyone! I have gone through several posts about audible clicks in groove~ and didn't see an option that pertains to my case. My patch is very simple, its a sequencer changing random start points. Of course, each trigger has an audible click, most likely due to the zero crossing.
Envelopes didnt seem to help after a few sessions trying them.
I would love to use groove~ because i love the sound of the timestretching. So grooveduck~ isn't an option for this patch.
I am looking to ideas on how to fix this on my own. I actually tried to delay the start point bang and simultaneously have a reverse envelope that would "silence" the clicks but it didnt quite turn out how I liked. I suppose before I actually post the patch I would love to hear any theoretical ideas on remedies for this situation. I have a feeling I might have to start from scratch and implement this from the ground up.
Any thoughts? :)
Hi, you could use curve~ or line~ to ramp-down amplitude before a change,then its right outlet can bang the actual change, followed by its own ramp back up in amplitude... i've done this before, it works, but here's a switch-and-ramp technique in gen~ which can sound faster.. the only probs it might have is that sometimes it can miss if your scheduler is not in overdrive(plus audio-interrupt with smaller vector sizes can help even more), and depending on the size of the change at the point of change, it can still sound like a 'bump' even if not an altogether 'click'... this bump can also be tricky to deal with when mastering(compressors/limiters will get tripped up too exaggeratedly), so it's also better to use it with a little headroom left over... i employed a bit too much here, you could probably get away with less than 4%(0.96 or so, instead of the 0.88 value i use here), anyways hope it helps:
Thank you! This does help! I implemented it in the patch and seems to work. Sometimes it can be tricky to understand where the clicks are coming from with this and an envelope. Appreciate your time on this
Hello!
I am from the future (2023) and tried to use the solution of 👽R∆J∆ The Resident ∆lien👽 but is clicking like crazy.
Did something change in the meantime in Max and it does not work as it use to be (ah those good old days)?
Any insight?
To recap, the issue is every time I try to instantly restart the sample with groove~ it clicks. I also tried to implement a ramp, but did not work as expected.
because you don't know how to implement it ?
you need to fade out, then start from new position and fade in.
fading length depends on audio material and acceptance threshold for abrupt changes in audio stream.
or use 2 players an crossfade them.
hmmm... that old 'switch-and-ramp' often had problems, and now it does seem as though it's reacting differently. i don't feel like investigating it either because i don't like de-clicking that is dependent on linear slopes(and i always found strange cases where 'switch-and-ramp' wouldn't work nicely)...
instead, nowadays, i'm just using this which may feel less exact since it's not sample-accurate in terms of the reaction-time for control, but it feels pretty perfect for general usage, and also, is probably not as cpu-intensive as using an all-gen~ or all-signal based solution:
here's that same patch simplified with the above:
hope this helps a bit(groove~ has timestretch with quality sound anyways now, and there's also the phasegroove~ object to help synchronization with de-clicking better: someone(not me) should try using phasegroove~ with groove~ within poly~ to get proper/efficient crossfaded granular detail)
🍻
in theory it is simple. a "click" is only how you perceive the presence of a a short time period which contains very high frequencies, so you can get rid of it by lowpassfiltering the audio during that short moment.
in practice you will find that it is impossible to find a perfect setting which works with any material: sometimes a click won´t matter at all, sometimes you can still hear a decent, unwanted "plop" after you applied a fade-in of 10 ms.
however, as a starting point the [slide~] object should be it.
and while not beeing ideal, i would suggest to use a buffered envelope for it, which you can read from with interpolated values (play, wave, cycle), because you really want to use a curved fade-in and not a linear, "trapezoid" fade-in which again contains a "corner" at its end, which produces a click again (which is why raja uses curve~ and not line~), and writing it into a buffer is for sure cheaper than to calculate it live
in opposite ot poles and zeros slide~ cannot explode, but to modulate it with a ramp from 0 to 22 khz you needed to transform its "sample" arguments into hertz first.
some people would say that you should modulate both the frequency and the steepness (use 4 slide in a row and mix their output level against the unfiltered signal), but for me it is an either/or case.
of course my statement is wrong. if you use frequency filtering, you need to fade-in the amplitude, too. if you do not, it stops working when the sound event (and the fade-in) is retriggered. but you can use only amplitude modulation without filtering.