tapin/tapout vs. delay: am I imagining this?

Feb 23, 2012 at 10:51pm

tapin/tapout vs. delay: am I imagining this?

As I understand it from the documentation, the smallest delay you can do with the tapin/tapout combination is one signal vector size. According to the delay~ reference, you can have delays smaller than the vector size, thus creating 1-sample delays. However, if I add a number equivalent to the vector size to the desired number of samples, then convert to ms, tapin/tapout *appears* to behave just like delay~. Am I imagining that? Adding to the size of the delay for tapin/tapout doesn’t make sense to me.

– Pasted Max Patch, click to expand. –
#61946
Feb 24, 2012 at 6:45am

Hi bkshepard,
In understand your patch and you illustrate that indeed with tapin/tapout a signal vector delay is added and with delay~ it isn’t. I agree with you that it would be more useful if this was done internally and signal vector size independent, automatically limiting the smallest delay to the signal vector size.

btw bkshepard, where did you read about this in the documentation? I could not find it in my quick search

what do the cyclists think?
will it break too many old patches too change this? probably

Timo

#223725
Feb 24, 2012 at 10:42am

tapout~ should definetly not do that.

when i remember right, that was a bug in 602 which should be fixed by now?

#223726
Feb 24, 2012 at 11:02am

yeah, something is wrong, here is another patch to illustrate it better, apparently, the signal vector size is subtracted from the tapin/tapout delay, this is not the case in max 5:

– Pasted Max Patch, click to expand. –

I will report it as a bug

#223727
Feb 24, 2012 at 5:13pm

Yeah, it was always my understanding that tapout could not have a delay smaller than the signal vector size, while delay~ could have a delay smaller than the vector size. Unless I’m totally misunderstanding–always a great possibility–it looks as if the vector size is somehow being automatically subtracted from tapout.

BTW, the best description of the difference between tapin/tapout and delay is in the delay~ reference documentation. In the Max 6 reference, you have to click the “Discussion” arrow to reveal the following:

The differences between delay~ and tapin~/ tapout~ are as follows: First, delay times with delay~ are specified in terms of samples rather than milliseconds, so they will change duration if the sampling rate changes. Second, the delay~ object can reliably delay a signal a number of samples that is less than a vector size. Finally, unlike tapin~ and tapout~, you cannot feed the output of delay~ back to its input. If you wish to use feedback with short delays, consider using the comb~ object. Note: While the delay~ object lets you specify time in any of Max’s standard time formats, the interval attribute argument should be used when specifying time in any other time unit besides milliseconds or notevalues (e.g. delay 22050 @interval 11025 samples).

#223728
Feb 24, 2012 at 5:41pm

good digging through the docs! I never noticed any discussion arrow (and it is not visible when you use the reference in the side-bar)

I got word back from cycling that the bug is acknowledged (and ticketed)

#223729
Feb 24, 2012 at 6:54pm

I hadn’t noticed the discussion arrow either. I actually found the description in my old Max 5 reference file and was wondering why I didn’t see that in the Max 6 doc. That’s when I noticed the little arrows. Oh well, live and learn…

#223730
Feb 24, 2012 at 8:51pm

It appears tapin/out is aware of whether there’s feedback or not.

– Pasted Max Patch, click to expand. –
#223731
Feb 24, 2012 at 9:05pm

…and it changes based on the amplitude of the feedback.

– Pasted Max Patch, click to expand. –
#223732
Feb 24, 2012 at 9:59pm

dislike +1

#223733
Feb 25, 2012 at 9:50am

@jvkr: oh yes, with feedback it is correct…
@bkshepard: I am not sure what you try to point out with the amplitude dependence, since in your example you cannot use the [!-~] comparison anymore

#223734
Feb 26, 2012 at 7:43am

Sure you can, I use [!-~] all the time. What I’m showing is that the example on the right completely cancels out at 0 with the signal vector size offset, while the one on the left does not.

#223735
Feb 26, 2012 at 1:09pm

Trying to get a better understanding of what is actually going on I produced this patch. Part of the issue can be considered a bug. Part of it a different interpolation scheme, I guess.

– Pasted Max Patch, click to expand. –
#223736
Feb 26, 2012 at 6:25pm

Yeah, when initially chasing down this questions, I came across this thread and this thread about the fact that using a signal from sampstoms~ rather than the float output has a one sample difference.

#223737

You must be logged in to reply to this topic.