## Sub-milisecond tapin/out?

Jun 14, 2013 at 7:01am

# Sub-milisecond tapin/out?

I’ve got a working looper using tapin/out. And it works great, click free etc….but I want additional loops to be fractions of the length of the first, some longer, some shorter, all based on the length of the first recorded loop.

However, subsequent loops are drifting by a milisecond at a time because tapin/out doesn’t interpolate.

It’s working so smoothly apart from that, and I really don’t want to go down the ~groove ~buffer ~rec route unless I have to – it’s been a big headache in the past for me!

Could someone tell me if buffer recording is the only way? Or is there a synching thing I need to read about?

Thanks everyone,

Lee Morgan

#252742
Jun 14, 2013 at 8:45am

I was surprised to learn this, but it does look like tapin~/tapout~ doesn’t interpolate with delay times < signal vector size. It does for those greater than the signal vector length, so I don't think this is the source of your problem. There may be some drift caused by the interpolation, however, since fractional delays are a compromise solution. It does take a while to manifest (depending on delay lengths), however, since the shift shouldn’t exceed 1 sample per cycle. If that’s still too much, calculate your delay in samples, convert it to an int, then multiply and reconvert to ms. You should get a non-fractional delay (or very minimally fractional depending upon some vagaries of floating point math? — let’s see if that summons Peter Castine) that will not drift. (the example on the right)

From your description, I think the drift may have a different source: I’m guessing you may be converting some of your delay times to ints accidentally via something like this: “* 2″ (or “/ 2″) instead of this “* 2.” That would account for it happening in ms rather than in samples.

<code>

– Pasted Max Patch, click to expand. –

</code>

#252752
Jun 14, 2013 at 9:06am

Thanks Peter – really helpful. And delighted if I don’t have to abandon the tap in/out method of looping! Will try it later….

#252753
Jun 14, 2013 at 1:24pm

yeah, I’m having a blast of a time looping with tapin~ + tapout~. My performance patch goes from tuned comb-style sounds up to a four-bar loop, and it’s really incredibly tight, I have no perceivable drift so far.

#252793
Jun 14, 2013 at 3:37pm

“tapin~/tapout~ doesn’t interpolate with delay times < signal vector size."

i am confused by this. does not interpolate? it should not even be possible to have delay times smaller than one vector, isnt it?

about the shift: wasnt there a bug which adds 1 ms or 1 sample to tapout~ in an earlier version of either max5 or max6?

-110

#252811
Jun 14, 2013 at 11:53pm

I was surprised, too, Roman. It’s definitely possible to have delay times shorter than 1 sig vector, but apparently interpolation ceases. (At least it does in the code I posted!)

This is probably a good question for the C’74 folks…

Not sure on the bug; this code is from the latest.

#252824
Jun 15, 2013 at 4:07am

Hmmm, on my system I don’t manage to get delays smaller than sig vs.

Concerning the original question, I see drift when the delay time is provided as a signal. Therefor I don’t understand this conclusion:

“However, subsequent loops are drifting by a milisecond at a time because tapin/out doesn’t interpolate.”

<code>

– Pasted Max Patch, click to expand. –

</code>

#252834
Jun 15, 2013 at 9:15am

FYI…

<code>

– Pasted Max Patch, click to expand. –

</code>
<code>

– Pasted Max Patch, click to expand. –

</code>

#252851

You must be logged in to reply to this topic.