live reverse tape effect
Hello there,
I have a small problem with a patch I've made that replicates the reverse tape effect, which I hope to later use as a sort of tap on/off stompbox unit. You switch it on, it records, then switch it off, then it automatically plays back. It handles forward, reverse, and float speeds.
The problem is that when you retrigger the unit whilst it's already playing back, and you trigger at the moment when it cuts off a sound, there's a click artefact. It doesn't happen if you interrupt playback when the buffer is playing back silence or a low amplitude signal.
I added a line~ to try and mute the entire output at the instant you retrigger, but the problem still persists. I'd be very grateful for anyone with some thoughts about what I'm doing wrong.
Hi NM,
From what I can see, the culprit is the 0 message you're sending [groove~], ie. resetting the playback position to 0. This is not delayed in any way and so happens just as your [line~] fade is starting. In fact, you probably only want that message sent at trigger OFF anyway, when you're getting ready to play the new recording.
The other thing I noticed is that you use the message (1., 0. 40) for the ramp down - why set it to 1 first? If you trigger it after playback has stopped, that [line~] will have been at 0 already, so will jump up before ramping down again (though nothing would be heard as your groove~ will be at 0 speed as well). If you happen to retrigger as the fade from the previous playback is in progress, you will get a click.
Also, how come you're also using a [line~] object for [groove~]? Unless you're going for a speed-up/slow-down effect, that's not necessary. (And the slow-down happens after the fade-out anyway.)
And finally, at the risk of straying into unsolicited code review: I wouldn't use delays to ensure certain events happen after the [line~] ramps - especially not one event at 45 ms and the next at 50 ms. Better use the right outlet of [line~], and [t] objects. That might mean you have to use separate [line~] objects for ramping up and down, but I'd say that's still more elegant, and safer, than setting off separate scheduler processes, especially when you're adding 5 extra ms here and there for good measure. In general, the way you use [t] and [sel] could use a big tidy.
Hope that helps!
Thanks for your thoughts BAFFALOP, they're very useful. Sorry for the slow reply.
You're totally right of course about the un-delayed 0 message before the groove~, and the lack of a [sel 0] to set it only on trigger off position.
Thanks for the notes on the line~ object messages too, indeed there's no reason to start from 1 each time when fading off, and I'll take your advice on using separate line~ objects and their bang-when-finish-output instead of delays each time.
As for your question about the line~ before the groove~ controlling the playback speed - at one time I thought that clicks could also be caused by the playback speed signal starting instantaneously at 1 or 0.5 etc. so I added the line~ to rapidly speed up and down the groove~ speed at the beginning and end of the sample playback (matching the fading in and out of the sample). I'm not sure if it's entirely necessary, but right now and after your edits, there are no clicks, so I'm happy!
Cheers!
Great news, glad that helped!
Yeah, there shouldn't really ever be a need to rapidly speed up/slow down to avoid clicks; that's what micro-fades are for.