11OLSEN

I have a groove~ playing a buffer. When i'm replacing the sample in the buffer during playback there's a click.

I'm trying to get around this click since 3 days without adding artificial delays. I was assuming that it should work when i'm fading to 0 before i replace the sample but that isn't enough. That gives me headache.

Edge~ reports the signal is 0. but the click still happens. I become suspicious that this has something to do with audio buffer or io vector. I have to add del 100-200 after fading to 0. to not hear the click. O.

I have a groove~ playing a buffer. When i'm replacing the sample in the buffer during playback there's a click.
I'm trying to get around this click since 3 days without adding artificial delays. I was assuming that it should work when i'm fading to 0 before i replace the sample but that isn't enough. That gives me headache.
Edge~ reports the signal is 0. but the click still happens. I become suspicious that this has something to do with audio buffer or io vector. I have to add del 100-200 after fading to 0. to not hear the click. O.
Any idea?


the-click-when-buffer-is-replaced-during-playback

fade to 0 before replacing the sample(as you're doing), but then use the bang that comes out buffer~'s right outlet to fade back up(it reports a bang out the right outlet when done replacing/reading a file).

There are too many unknowns for one to be able to advise you without seeing your patch, but...

99% of the time when someone says, "How do I get rid of the clicks in MSP?" the answer is "Use line~ to interpolate smoothly from one thing to another."

In your case, instead of switching instantaneously from one sound to another (which will almost certainly cause a click), or even ducking the volume down to 0 before switching (which will still cause an annoying discontinuity), why not crossfade quickly (or slowly if you prefer) from one sound to another?

i'm already waiting for the buffer bang. the click seems not to occur at retriggering. it happens when the buffer change is triggered after fade-out.

thanks dobrian, i really know this 99% solutions. i wouldn't have asked here without doing some research on my own. as the project is a one-voice-sampler instrument i tryed to avoid adding more than one buffer~ to it but that is probably necessary to get this sample changing clickless.

I was jus' sayin' that even without seeing your patch I could guess the culprit. If you don't want to load the sounds in advance, and you can live with the slight latency involved in loading the new sound into the buffer~, you can still use this back-and-forth crossfade technique with just two buffer~ objects and two groove~ objects.

I don't want a fade-in for the next sample.

This simplified version WORKS as i expect.

In my patch the groove~ is in a poly~ with adsr and muting involved. What makes the tests time-consuming is that the anti-click methods work as long as the device is opened in the m4l editor but not in Live. O.

This simplified version WORKS as i expect.
In my patch the groove~ is in a poly~ with adsr and muting involved. What makes the tests time-consuming is that the anti-click methods work as long as the device is opened in the m4l editor but not in Live. O.


edited: nevermind :p ("I don’t want a fade-in for the next sample."...finally understood this by your patch :)

i now found out: when i'm resampling the output of Live the material is recorded clean as if the clicks were not present.

That means the clicks are not max related, instead they are Live audio thread or asio driver dropouts when the sample loads but why?

That also explains why the clicks don't occur in m4l editor. The editor is using it's own thread as far as i know.

Seems that the priority for loading into buffer~ seems to be extremly high, it is not even played by any object at this moment.?

The clicks are gone when i increase the asio buffer. I could have searched forever in the patch for the problem.

Like always it helped to post the question here. thanks for your answers..

But still, i won't work with unnecessary high latency/buffer if everything works, only loading into max buffer causes a peak.

i now found out: when i'm resampling the output of Live the material is recorded clean as if the clicks were not present.
That means the clicks are not max related, instead they are Live audio thread or asio driver dropouts when the sample loads but why?
That also explains why the clicks don't occur in m4l editor. The editor is using it's own thread as far as i know.
Seems that the priority for loading into buffer~ seems to be extremly high, it is not even played by any object at this moment.?
The clicks are gone when i increase the asio buffer. I could have searched forever in the patch for the problem.
Like always it helped to post the question here. thanks for your answers..
But still, i won't work with unnecessary high latency/buffer if everything works, only loading into max buffer causes a peak.    

so sorry to be giving such in-the-air guesses.... but with m4l devices loaded into live, i heard that 'overdrive' is always on(?).... so maybe try experimenting with adding a defer or deferlow to alter this:

"Seems that the priority for loading into buffer~ seems to be extremly high"

so sorry to be giving such in-the-air guesses.... but with m4l devices loaded into live, i heard that 'overdrive' is always on(?).... so maybe try experimenting with adding a defer or deferlow to alter this:
"Seems that the priority for loading into buffer~ seems to be extremly high"


i'm afraid that doesn't help. it's how the buffer~ external works inside. Nevermind, i'm feeling better now that i know it's not an error in my patch logic.

I do not want mess, but with a gen "codebox" with some: [for 

I did not find a command that serves to decrease the execution time, priority, of codebox for etc. .. so I'm trying to divide by the "for" in chunks, guided by count + = ~ ~ or something, driven by audioclock.

I do not want mess, but with a gen  "codebox" with some: [for 
I did not find a command that serves to decrease the execution time, priority, of codebox for etc. .. so I'm trying to divide by the "for" in chunks, guided by count + = ~ ~ or something, driven by audioclock.

I wonder what the "clearlow" message to buffer~ is intended for. need a "readlow". maybe an external with a systhread filling the buffer~ is possible.?

the click when buffer~ is replaced during playback