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

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

    • Feb 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
    • Feb 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?
    • Feb 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:
      I will report it as a bug
    • Feb 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).
    • Feb 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)
    • Feb 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...
    • Feb 24 2012 | 8:51 pm
      It appears tapin/out is aware of whether there's feedback or not.
    • Feb 24 2012 | 9:05 pm
      ...and it changes based on the amplitude of the feedback.
    • Feb 24 2012 | 9:59 pm
      dislike +1
    • Feb 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
    • Feb 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.
    • Feb 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.
    • Feb 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.