how do i stop the snap crackle and pop on a buffer groove
i know this is an age old question asked many times but Ive trawled through the backlog of threads of the issue and come to no conclusion.
Ive heard it may be a driver/latency issue but also that the groove create a click when the playback position is changed.
Is there an object which can be used to stop this?
I understand people will have heard this question a million times but ive not been able to get to the bottom of it.
On Apr 11, 2008, at 8:16 AM, Toiletmuck wrote:
> i know this is an age old question asked many times but Ive trawled
> through the backlog of threads of the issue and come to no conclusion.
>
> Ive heard it may be a driver/latency issue but also that the groove
> create a click when the playback position is changed.
>
> Is there an object which can be used to stop this?
Any time you change position of playback in an audio file you will
probably get clicks, unless both the source and destination points
happen to be at a zero crossing (highly unlikely).
If you want to post a patch, perhaps there's something that can be
done with quick fadeins and fadeouts, using line~ and *~
-C
Chris Muir
cbm@well.com
http://www.xfade.com
poor quality patch but if you could help that would be amazing
some sort of windowing / ramping should help it out alright
clipping the buffer size or something?
ah the rampsmooth object seems to work fairly well, the clicks are almost inaudible :)
is there a windowing function?
One of the tap tools could help too: tap.snap~ is very clever, as it snaps to the nearest zero point. You could use that to dodge clicks, rather than palying around with ramps, which I always find cheating, somehow.
It could be fiddly, but then, it also means sustaining sounds stay that way.
Best,
Lee Morgan
use grooveduck
u find it in examples into max folders...
On 12 Apr 2008, at 19:57, Lee Morgan wrote:
>
> One of the tap tools could help too: tap.snap~ is very clever, as
> it snaps to the nearest zero point. You could use that to dodge
> clicks, rather than palying around with ramps, which I always find
> cheating, somehow.
>
> It could be fiddly, but then, it also means sustaining sounds stay
> that way.
>
> Best,
>
> Lee Morgan
grooveduck? i dont have that
Quote: Lee Morgan wrote on Sat, 12 April 2008 12:57
----------------------------------------------------
> One of the tap tools could help too: tap.snap~ is very clever, as it snaps to the nearest zero point. You could use that to dodge clicks, rather than palying around with ramps, which I always find cheating, somehow.
Sounds like an interesting object. I may download the demo of that object collection at some point, but I like to save my 30 day demos for times when I really have time to use them.
Could you tell me a little more about this tap.snap~ object? It sounds neat, but before I go wasting demo time on that collection (who knows, I may want to try it later for other reasons) I want to find out if it really does what I'd be interested in.
How do you control this object? My guess is that you tell it a time in your buffer and then it outputs the time that corresponds to the closet zero crossing? Is that right or am I completely off base? Also, do you have any idea if it finds the closest crossing in either direction? or does it only look for the next zero crossing after the time you enter or something else like that?
Any other info you got on this object would help me figure out if I want to check it out. Sounds like a tempting external, but as I'm saving up for the IRCAM Forum subscription, not really sure what I think about paying for more objects.
I confess - my tap.tools has expired too, and by coincidence, I'm thinking of getting the IRCAM stuff. But FYI, here's the tap.snap help file, useless without the object I know, but it'll give you a handle on how it works. As I remember, it looks either side of the given point, and 'snaps' to the nearest zero crossing - usually it's very close, of course...I built a similar patch to yours, and it certainly worked for removing the clicks.
Lee
ps looking at it again, I see it refers to a "built-in snap-to-zero-crossing feature" on the waveform object - news to me! Worth checking the manual for....
I think all you need is [waveform~]
you can set the zero-crossing snapping behavior in its inspector.
regards,
kjg
ok, it says to use the built in snap to zero function would make more sense than this tap object.
so where is the built in snap to zero function on the waveform~?
Quote: Nano59 wrote on Sun, 13 April 2008 17:51
----------------------------------------------------
> ok, it says to use the built in snap to zero function would make more sense than this tap object.
>
> so where is the built in snap to zero function on the waveform~?
----------------------------------------------------
you can set the zero-crossing snapping behavior in its inspector.
regards,
kjg
tried that, its still the same.
Could someone test the patch with a soundfile and see if it's different for them please ?
works fine here. try it with the vibes sample. swithc between "none" and "zero" for the snapping options and then make your selection...
regards,
kjg
ive tried other sound files and some seem to be fine really, even though a lot of them were recorded with the same mic. The two that have clicks all over them are a recording of a bass guitar and a recording of my accoustic guitar with my rubbish laptop onboard mic (only to test it)
maybe its my soundcard or my speakers. Or the fact that I have no ASIO driver
I looked at your original patch Nano as well as what KJG posted I think I have figured out the info you need.
If I understand correctly, in your original patch you want to send a start and end point to [waveform~] and have [waveform~] readjust those points to be at a zero-crossing. From my past experience, [waveform~] does not operate in this way regarding snap-to-zero but in the way that KJG demonstrated where it snaps on mouse input only. In playing around with KJGs patch, I made a discovery new to me which is that if you resend the "snap zero" command after you have sent your int/float start/end points to [waveform~] via inlets it will readjust the values you sent to be at zero-crossings.
If you want to see this in action, add numberbox input to KJG's [waveform~]. When you enter some numbers in your boxes you will hear clicks. To remove the clicks, reselect "zero" from the pulldown menu and [waveform~] will readjust.
Before I get into how to automatically do what I just described so that you don't have to hear clicks until you reselect "snap zero" there are a few other things about your original patch that I want to point out that may be other sources of clicks. I may be misunderstanding your goals, but there are a few problems I see.
-The LED you have going into [groove~] tells [groove~] to start playback at sample zero or sample one depending on the output of the LED. So this will cause a click because sample 0 or 1 is not necessarily a zero crossing for one thing and also the point you are jumping from in playback also may not be a zero-crossing. It looks like you are going to need to trigger [groove~] in another way. Possibly look into using a "startloop" message.
-The number boxes going into [groove~] are another source of a problem. I noticed these number boxes have two different inputs, one coming from [waveform~] and one coming from the pre-[waveform~] numberboxes. The is possibly defeating the purpose of using [waveform~] even if snap-to-zero is working correctly because of the non-[waveform~] inputs to your numberboxes. You will want to disconnect these so the numbers going to [groove~] are only being supplied by [waveform~].
Here is a version of KJG's patch that demonstrates how you can use [waveform~] to snap-to-zero on int/float input by resending the "snap zero" message after inputting your loop-points. This was a quick fix I made, so if someone has some better logic for how to program this more efficiently, please feel free to correct me.
P.S.
As far as I know, the solution I posted should be click free.
Keep in mind that even if you go to a zero-crossing it is still possible to create a very drastic zero to non-zero transition that while you will not have a true discontinuity click, it can be too harsh for some speakers to smoothly replicate and you may end up with a pop (I guess by pop I mean mellower than a true click).
I'm not saying you should give up on solving clicks by just blaming your soundcard or speakers, but I just thought I should mention that I have made pieces that were pop free on some speakers and then when I played them back elsewhere things were too harsh for the other system.
in the inspector snap grid , or check the docu on waveform~
On Apr 13, 2008, at 5:51 PM, Toiletmuck wrote:
>
> ok, it says to use the built in snap to zero function would make
> more sense than this tap object.
>
> so where is the built in snap to zero function on the waveform~?
Jacopo Carreras
music weaver
www.myspace.com/jacopocarreras
www.lan-muzic.com
On 2008 Apr 13, at 10:51 AM, Toiletmuck wrote:
>
> ok, it says to use the built in snap to zero function would make
> more sense than this tap object.
>
> so where is the built in snap to zero function on the waveform~?
In the case of that help patcher, yes. But sometimes you don't want
the extra CPU expense of waveform~.
Also, the tap.snap~ object can function as a signal object, meaning
that if you are recording into the buffer~ at the same time as you are
playing back then the zero-crossings will be updated with sample-
accurate timing. So it is still (for me, at least) more useful than
the feature in waveform~.
Also, because Tap.Tools 3 is coming soon, you could "game" the system
on demos. The demo period for Tap.Tools 2 and Tap.Tools 3 are
independent of each other. So you could download TT2 now, and then
when that demo expires you still could download TT3 whenever you want
and get 30 days more demo. :-)
best,
Tim
____________________________________
Tap.Tools - Objects for Max, MSP, and Jitter
http://electrotap.com/taptoolsmax/