leemorgan

I have (for other complex reasons) to use tapin/out to record, time (precisely) and playback a loop.

Was working great until I tried putting a fade in/out to stop any clicks.

Any advice? Wrong method of click elimination? At the moment when the line~ doing the fade out finishe it sends a '0' to stop the sample timer, and set the tapin~ length. So there is a 5 ms delay between stopping the recoding and that actually happening....maybe something happening there?

(p s- I can't use groove/snaptox on a buffer/grooveduck because of the rest of the patch -this is just the part that doesn't work:).

timing-line-to-eliminate-click-on-tapinout-looper

I just glanced at this, no time to test etc, but it looks like you are relying on your [sel 1 0] to perform a number of critical tasks, can I therefore suggest that you try using the [trigger] object to define and order events such as starting timers, opening/closing gates etc. This may well help

Hi
I just glanced at this, no time to test etc, but it looks like you are relying on your [sel 1 0] to perform a number of critical tasks, can I therefore suggest that you try using the [trigger] object to define and order events such as starting timers, opening/closing gates etc. This may well help

Yes, I see all the pros using t objects in their patches and wondered why I never needed them - I'll investigate....thanks Brendan.

Can't seem to get that to help (using trigger to first fade in/out and second open/close gate and time the tap in object....) but then, this is my first time using trigger...

You're going to be way better off using buffer~. Then you can use wave~, trapezoid~, and rate~.

I'd also recommend padding your times so it ducks for a few ms longer than needed in order to account for scheduler slop before things get to line~.

You're going to be way better off using buffer~.  Then you can use wave~, trapezoid~, and rate~.

I'd also recommend padding your times so it ducks for a few ms longer than needed in order to account for scheduler slop before things get to line~.


your patch doesn't look like it has any ducking/ramping in the right place after tapout~...

just look in the tapin~ or tapout~ help file, see the subpatcher there called "[p avoiding_clicks]"... just like it shows there, you need a ducking technique for whenever you change the delay of tapout~(you'll also see there how trigger is used properly for this technique as Brendan suggested).

the way you have line~s for the cycle~ is fine, but you also need to have something for the delay-time change(especially when you have a feedback path).

[edit: using wave~ with buffer~ like Peter suggested, though, is probably better for looping... the way you're changing tapout~ delay time isn't sample-accurately synced anyways... ]

just look in the tapin~ or tapout~ help file, see the subpatcher there called  "[p avoiding_clicks]"... just like it shows there, you need a ducking technique for whenever you change the delay of tapout~(you'll also see there how trigger is used properly for this technique as Brendan suggested).

[edit: using wave~ with buffer~ like Peter suggested, though, is probably better for looping... the way you're changing tapout~ delay time isn't sample-accurately synced anyways... ]


awww shit, looks like cycling74 removed the [p avoiding_clicks] subpatcher from the tapin~ and tapout~ helpfiles in Max6(this doesn't seem like the best decision(?)... HEY CYCLING74! small request: if you're going to take stuff like this out of helpfiles, maybe at least put it into tutorials, like for this one, maybe in MSPTutorial28: Delay Lines With Feedback... just a suggestion from your favorite, friendly, local, resident-asswipe :D...).

so here it is from Max5 in case you need it:

Thanks Raja - I didn't know about this. Will try it now...

Haaahaha. You know what ? the subpatcher avoiding clicks is still in max6 helpfile, ONLY it's not in the tabs... if you right click the upper part of the patch (right of the existing tabs) you can check "show root patcher on parent", then a "basic" tab appears when you can see a subpatcher "p avoiding clicks". It's so odd it's either something that slipped from the update, either intentional for some reson ;)

then you can double click it, cmd shift i : patcher inspector, tab "all", check "show on parent patcher tab". Now it's in the tabs.

Haaahaha. You know what ? the subpatcher avoiding clicks is still in max6 helpfile, ONLY it's not in the tabs... if you right click the upper part of the patch (right of the existing tabs) you can check "show root patcher on parent", then a "basic" tab appears when you can see a subpatcher "p avoiding clicks". It's so odd it's either something that slipped from the update, either intentional for some reson ;)
then you can double click it, cmd shift i : patcher inspector, tab "all", check "show on parent patcher tab". Now it's in the tabs.


oops - thanks for finding that, we'll fix it up for the next thing.

I don't know whether these will be helpful to you, but here's a set of several examples (

) with a discussion of click-avoidance when changing delay times.

I don't know whether these will be helpful to you, but here's a set of several examples (examples 17-23) with a discussion of click-avoidance when changing delay times.


Thanks Christopher, very happy to look through these.

I think (just to answer Peter) the reason I'm wedded to tapin/out rather than buffer recording is that I don't need any of the extra bells and whistles that come with groove~ etc. I don't need to change speed/direction/loop points or any of that. Just the loop is fine (as long as the timing is precise) and, despite reading pages of forum advice, trying grooveduck, tap.buffer.record, snap to zero on waveform, etc.....I still seem to get less clicks whenever I use tapin delays that start as soon as the recording has been made (al a guitar loop pedal) instead of buffers.

I can manage click-free loops when selecting a section in a waveform and doing the snap to zero thing. But I need more immediacy than that.

But there are so many posts about this - some that refer to threads that refer to other threads - that I feel I must be missing something.....but I'll plough on. Thanks everyone!

I think (just to answer Peter) the reason I'm wedded to tapin/out rather than buffer recording is that I don't need any of the extra bells and whistles that come with groove~ etc. I don't need to change speed/direction/loop points or any of that. Just the loop is fine (as long as the timing is precise) and, despite reading pages of forum advice, trying grooveduck, tap.buffer.record, snap to zero on waveform, etc.....I still seem to get less clicks whenever I use tapin delays that start as soon as the recording has been made (al a guitar loop pedal) instead of buffers. 

But there are so many posts about this - some that refer to threads that refer to other threads - that I feel I must be missing something.....but I'll plough on. Thanks everyone!


"I don’t need to change speed/direction/loop points or any of that. Just the loop is fine (as long as the timing is precise)"

Peter mentioned wave~. Wave~ does not have many added bells and whistles and if you want even less, you could try out index~ or play~, too(the fact that you have to couple a tapin~ to a tapout~, and then while desiring 'precise timing' you still only use scheduler-based messages(instead of sample-accurate signals) to control changing delay-times, means you're already doing something more convoluted and less precise than the other techniques).

"But there are so many posts about this – some that refer to threads that refer to other threads – that I feel I must be missing something…..but I’ll plough on."

Ha, so true. Plough on and best of luck.


Timing line~ to eliminate click on tapin/out looper