Tim Lloyd

I've been toying with the idea of making a delay which has a function like the one at the beginning of this video:

http://www.youtube.com/watch?v=4zH3EcXWJVs

Here is a little patch that records the tapped rhythm into a buffer, I want to try and keep the whole thing signal based, which is why I'm trying it this way.

Problem is, I can't think how to translate the rhythm in the buffer into some way of creating a rhythmic delay.

rhythmic-multitap-delay

i think you should forget the idea of using a signal 

to preserve a high accuracy of something tapped with 

using data would have a great advantage over signal here,

as you could implement quantizing easily and then have it 

bang, [timer], [zl reg], [tapout~ 10. 10. 10. 10. 10. 10. 10. 10. 10. 10. ] is all you need.

i think you should forget the idea of using a signal 
to preserve a high accuracy of something tapped with 
your fingers.

using data would have a great advantage over signal here,
as you could implement quantizing easily and then have it 
as accurate as it can be.

That's a good point, I'll do it using data. I'll still explore using signals though, and try and create it without using tapin/out, just to see what happens.

I'm not sure what they are yet, but there might be some interesting variations of the concept that could be done more easily using signals. I'll have to keep trying and see!

One issue with using tapout~ that quickly comes to mind is that it instantly imposes a limit on the number of "notes" that can be in the delay rhythm. Hopefully I'm wrong about that though. I could always just give it loads of outlets, but it seems like there might be a more interesting way of doing it, going back to the signal idea. hmm

That's a good point,  I'll do it using data.  I'll still  explore using signals though, and try and create it without using tapin/out, just to see what happens.  

I'm not sure what they are yet, but there might be some interesting variations of the concept that could be done more easily using signals.  I'll have to keep trying and see!

One issue with using tapout~ that quickly comes to mind is that it instantly imposes a limit on the number of "notes" that can be in the delay rhythm.  Hopefully I'm wrong about that though.  I could always just give it loads of outlets, but it seems like there might be a more interesting way of doing it, going back to the signal idea.  hmm


you could use [poly~ mytapout 64] instead of 

[tapout~ 100. 100. 100.] in order to get more 

than 10 outputs (i think its limited to 10 but

i might be not up to date with my max version), 

and to save CPU when only 3 outs are needed.

btw: you may even connect the polyfied tapout to

one single tapin _outside the poly object ...

the problem with poly is, of course, only that

things like a filter per delay or panning per delay

would have to be inside the poly patcher, too.

you could use [poly~ mytapout 64]  instead of 
[tapout~ 100. 100. 100.] in order to get more 
than 10 outputs (i think its limited to 10 but
i might be not up to date with my max version), 
and to save CPU when only 3 outs are needed.

btw: you may even connect the polyfied tapout to
one single tapin _outside the poly object ... 

the problem with poly is, of course, only that
things like a filter per delay or panning per delay
would have to be inside the poly patcher, too.

I am using exactly that without problem. The tapout~ in a poly~ the tapin~ outside connected with a simple send/receive. That way changing the maximum number of taps is as simple as sending a voice $1 or typing a number into the poly~ object. Works like a charm...

rhythmic multitap delay