Holiday notice: Cycling '74 will be closed Monday, October 9th. Manual authorization, support cases, and manual order processing will be delayed.
Tempo based Sampler - Having trouble with clicks
Aug 25 2012 | 1:11 pm
I have this 'chance' sampler made for me by my teacher that operates via transport. I can set the probability of recording and then playing back from a buffer~, and the transport picks a random pitch and a random point in the sample to play from. It's very prone to clicks, however, and I can't work out a system that gets rid of them. I tried adsr~, but the clicks are being caused by a bang that picks the point of the sample and the pitch (rather than a signal), so that doesn't work. I also tried using line~ to quickly drop the amplitude, then bring it back up again (using a message like 1, 0 25 1 25), but that doesn't work either. I thought about using function, but I can't get my head around how that object works.
I hope that makes sense. Basically, I need something that will detect the bang that chooses the pitch and point in the buffer~, then drop the signal and bring it back in quickly, eliminating clicks. Can anyone offer some hints? I'm not after someone to fix this for me, just point me in the right direction.
Thanks!
- Aug 25 2012 | 2:34 pmHi [groove~] clicks are often masked using the [trapezoid~] object, as shown below, although to avail of [groove~]'s sync outlet I did have to make one subtle change to your patch. Doesn't appear to have undermined the functionality.....any clicks that remain appear to reside inside the buffer, perhaps due to the overdub method you're usingBrendan
- Aug 25 2012 | 2:38 pmyeah i'm gonna need to work on this further; your probability engine is sometimes triggering a new audio event, before the previous one is finished - hence the clicks even WITH the trapezoid envelope....
- Aug 25 2012 | 10:08 pmI've not looked at your patch but if I understand correctly this will be handy to you. It's an abstraction I made to be to jump around willy nilly without clicks.I have a premade hanning window type thing which is driving wave~, but the idea is that you start fading out, then send the message to whatever playback object, then fade back in.
- Aug 25 2012 | 10:37 pmI haven't looked at the patches, but from what I hear I think you can use Brendans solution. But then implement it in a [poly~] to solve the problem of simultaneous events that Bredan talked about.If you don't know about [poly~], read the helpfile. It's really handy.
- Aug 26 2012 | 9:28 amThanks for the help guys! Rodrigo, I'll try your idea today and report back.Brendan/Dave: I know about poly~ but never used it before. Will have a look and see if it's of any use.
- Aug 26 2012 | 12:38 pmMake sure you have a hanning window buffer first as it won't work as a straight 'line'.Here is my premade wave file, just have it in the same folder as the patch/abstraction.
- Aug 26 2012 | 7:31 pmSorry Rodrigo, I missed that in your original post. What's a hanning window buffer?
- Aug 26 2012 | 9:25 pmJust a waveform shape. Put that wav file from my last post in the same folder as the patch and it should load automatically into the code I posted earlier.More technically (not that I'm great at understanding this stuff anyways) but you can fade down and back up, linearly, so it would look like the letter V. This works, but it's not 'smooth' sounding, plus there's very little time spent fully quiet, for the jump to happen.The hanning window (http://cnx.org/content/m12032/latest/hann64.png) does the same thing, but smoothly. In the case of my code form earlier, I'm using an inverted hanning, to fade out, then back in. Windowing is often used for granular synthesis, in which case you'd want to fade a sound in, and back out. We want the opposite in this case, though the goal is the same in both. No click.
- Sep 24 2012 | 2:31 pmNot had internet for the past few weeks hence the late reply. I tried sending the 'append $1' message to record~ and it seems to be getting rid of clicks pretty nicely! It will do for now at least, but thanks again for your help guys :)
- Oct 02 2012 | 5:59 pmHello! Sorry to bring back an old thread but I'm still having some click issues. It's not so bad since I added "append $1" to the record~ in the patch, but I'm still getting the old massive click here and there. I've tried using function to create an envelope but I'm pretty sure I haven't done it right.This is more or less what I have. I'm using a bpatcher in reality but it's essentially the same. Is the function in the right place? Can I even use it for this kind of thing? I've tried adsr~ as well but couldn't work that one out. I've hit a bit of a wall to be honest. I'm sure it's not a complicated thing to do but it's defeated me for the moment! Any hints are appreciated.
- Oct 03 2012 | 1:13 pmHI Phil there are a number of problems with your patch, I spotted a couple of things which could cause clicks. To understand each issue you should get into the habit of breaking down the sections of your patch and troubleshooting each one.First potential problem is the way you record into the buffer. You are starting and stopping mid recording which will cause discontinuities in the recorded waveform. This may cause clicks on playback. This patch shows the effect:You can solve this a number of different ways, probably the simplest is to fade in/out the source at the start and end of the recording.The second place you might get problems are when the playback position overtakes/undertakes the record position - this will also cause discontinuities in the audio signal - play with this patch to see/hear the effect.This is not so simple to solve, but if you have a big buffer you can make sure the playback point is far enough away from the record point for it not to be an issue. It all depends on how long your playback sections are.Once you've sorted out getting a nice click free waveform recorded the third problem lies in the windowing/enveloping of the sample playback engine. to test your patch just attach a scope~ to the window outlet and watch it to get a sense of what is going wrong. Clicks can happen when you change the loop length while the sample is playing and when you re-trigger a sound when it's playing. A lot of these problems can be overcome by getting familiar with poly~ an using multiple voices.If you insist on using groove~ and not using signal domain for timing then adsr~ can be used to make sure that position/loop information is only changed while volume envelope is very near 0. Have a listen to these three examples:All the best,John.
- Oct 03 2012 | 8:02 pmHi John,Many thanks for this! I've had a look at the examples you showed me and it's making some sense why and where the clicks are occurring now. I'm going to dive into it more and make sure I'm not missing anything with groove~ before I have a go with play~ or wave~ (or poly~).Thanks again,Phil.
- Oct 03 2012 | 8:41 pmclicks are often produced when one sample is playing and another one is requested before the last one has finished playing. You usually fade in the sample, the envelope rises and if a new sample is requested the volume envelope has to fade down to 0, the new sample starts and the volume fades in again, if you get this wrong it's easy to get clicks. By having just two voices you can fade up A and if a new sample is requested before A has finished its ramp down you can start B ramp it up and tell A to ramp down. By having lots of voices you can have polyphony.
- Oct 07 2012 | 11:13 amSo this is what I have so far. I'm still getting clicks on the record~, but I can't figure out how else to fade in/out on that. I'm still getting the odd click, and when I use this as a bpatcher I get weird distortions in the output, which I didn't have before I put the adsr~ on the record~
- Oct 07 2012 | 4:58 pmActually, nevermind! I think I worked it out.
