Forums > MaxMSP

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

February 23, 2012 | 10:51 pm

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. –

February 24, 2012 | 6:45 am

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


February 24, 2012 | 10:42 am

tapout~ should definetly not do that.

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


February 24, 2012 | 11:02 am

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


February 24, 2012 | 5:13 pm

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).


February 24, 2012 | 5:41 pm

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)


February 24, 2012 | 6:54 pm

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…


February 24, 2012 | 8:51 pm

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

– Pasted Max Patch, click to expand. –

February 24, 2012 | 9:05 pm

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

– Pasted Max Patch, click to expand. –

February 24, 2012 | 9:59 pm

dislike +1


February 25, 2012 | 9:50 am

@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


February 26, 2012 | 7:43 am

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.


February 26, 2012 | 1:09 pm

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. –

February 26, 2012 | 6:25 pm

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.


Viewing 14 posts - 1 through 14 (of 14 total)