[delay] in gen giving a TOTALLY DIFFERENT signal than [delay~]!?!?

    Jan 28 2014 | 10:09 am
    It's impossible for me to get the same signal out of [delay] in gen and [delay~] in msp. (using signal as delay time)
    See patch.
    I tried different interpolations in gen (using @interp … as argument of [delay]), as well as adding a one sample delay, but there is absolutely no way i can get the same signal from [delay] in gen and [delay~].
    I'd really like to know what is going on!

    • Jan 28 2014 | 9:09 pm
      there are a few problems, such as adding dc offset to cycle~ and then some other weirdness, so i don't really understand your patch.
      however, i would say the main problem is you are comparing apples and oranges, as they say.
      [delay~] in MSP has almost nothing in common with [delay] in gen~. cycling74 seem to like calling different things similar names.
      [delay] in gen~ is a like for like replacement of a [tapin~] / [tapout~] pair, with some über extra features of course.
      i wouldn't ever use [delay~] for delays.
      i made a gen~ patch to demonstrate the basics. hope it helps.
    • Jan 29 2014 | 11:22 am
      Hi stkr,
      Well i really don't see how i could make this patch simpler, ok you can replace the cycle~ with the dc offset by a simple [phasor~ 0.4] if you want, this a just a source signal to vary the delay time from 0 to something...
      The only weirdness in my patch is this [+~1.] before the delay amount to gen, you can put it away but then the difference between gen and [delay~], in the scope~, gets wider in that case. This is because the [delay~] is delaying one sample more than the value you give to it, while delay in gen is delaying the right amount of samples, and only 0. sample become 1. sample. (This is effectively a bit weird and it would be nice if this would be documented)
      So, for int value of the delay time, gen and [delay~], give exactly the same result, the problem is that i cannot get the same result when using float signal values for the delay time.
      The interpolation must be different, and i would love to know where the interpolation is wrong... in [delay] in gen or in [delay~]?
      And it would be nice if cycling correct that so we can have at the same interpolation working on both... so we can transfer patches from msp to gen without stress. :-)
      The reason to use delay~ instead of tapout~ is because i'm doing a formant shifting algorithm using delay times that are constantly moving down to zero: tapout~ cannot delay less than a vector size.
      The max help is clear about what those delay object are doing:
      [delay~] in msp: delay a signal by a certain amount of time specified in samples.
      [delay] in gen: delay a signal by a certain amount of time specified in samples.
      …so i don't get what you mean by apples and oranges.
    • Feb 04 2014 | 12:28 pm
    • Feb 04 2014 | 3:37 pm
      What is really annoying is that, in my 'FastMonoPitchFormantShift' that i'm translating to gen, i get between 0.5 and 4 ms of latency more in gen than in msp depending on the shifting frequency!! But everything seems to be exactly the same... I feel there might be another place where gen and msp are doing different processes, but with this gen's delay and delay~ behaving differently, it's impossible to figure out where...
      It would be really nice guys at cycling, first tell us what is different in the processes in gen's delay and delay~, and second, implement a corresponding interpolation in gen's delay in a next incremental max version...
    • Feb 12 2014 | 6:45 am
      I don't know what was going on in your original patch but I'm getting the same output from each with this test:
    • Feb 12 2014 | 10:57 am
      @stringtapper gen delay and msp delay~ behave the same way for a delay time >= 1 sample (and no custom interpolation set gen side). The only difference happens for a delay time = 0, gen version keeps delaying of one sample while msp version is not delaying at all. It seems that gen delay operator has an inherent one sample delay even if zero sample is set, weird isn't it ?
      That's not much of a problem for most of the applications, but could be indeed for some precise msp to gen transcoding cases
    • Feb 12 2014 | 11:26 am
      Stringtapper, you didn't read me well in my message of the 29 of january: I said that, effectively, for INT VALUES of the delay time (or float as message that are converted to int), gen and [delay~], give EXACTLY the same result! fine.
      What going on in my patch is that the interpolation for "FLOAT values of the delay in sample sent as a SIGNAL" to the delay or delay~ objects, is different in gen or in delay~. And changing to different interpolation in gen doesn't help.
      It does not behave the same way matthieu.
    • Feb 12 2014 | 11:28 am
      here is right test patch to see the problem in case of doubt:
      (same as my first message)
    • Feb 12 2014 | 11:30 am
      The minimum 1 sample delay in gen is to support feedback. You can bypass it by adding @feedback 0 to the delay object. This will let you have delay times less than one sample.
    • Feb 12 2014 | 12:05 pm
      btw, what is the gen equivalent of the interpolation used in delay~ when controlling the delay time with signal floats ?
    • Feb 12 2014 | 12:19 pm
      Ok Graham, but it doesn't explain/revolve the interpolation-difference we get here.
      I believe that the "gen equivalent of the interpolation used in delay~" would in principe be "linear". but it's different.
    • Feb 12 2014 | 10:26 pm
      The gen delay object offers four options for interpolation (none, linear, cubic, spline), set using the @interp argument. The default is linear. There is a minimum delay of 1 sample to allow feedback patching, which can be disabled using @feedback 0. The cubic/spline interp options incur an additional minimum delay of 1 sample.
      Delay~ does use linear interpolation when the delay time is set by a message, but when set by a signal I believe it is using a 4-point sinc interpolation.
    • Feb 13 2014 | 12:09 pm
      " I believe it is using a 4-point sinc interpolation. "
      Thanks for the info! Could someone confirm that?
      So my feature request is: Could we have either this "4-point sinc interpolation" also implemented in [delay] in gen (or either the other way, having an option to use a cubic interp in [delay~]) so that it's possible in some way for those two SUPPOSEDLY IDENTICAL objects to give the SAME signal out?
      It would then be much more easy to debug patches while porting them to gen...
      Also, for info, i just made this "max-delays-interpolation-benchmarck" patch to compare interpolations:
      First this 'believed-sinc' interpolation of delay~ is better than the standard linear one in gen. (I think this sinc should be ported to gen and be the standard one instead of linear)
      But anyway, after debugging my patches i would put cubic interpolation which sounds better to me in most situation. (and also i filter my sound again after to make the spectrum be more soft, thus more natural) Cubic is filtering a bit better than cosine, and i have the feeling spline introduce some light resonance in some situations.
      I also compared those interpolations with 50 delay in gen on a mbpro i7:
      none: 3.6%
      linear: 6.0%
      cosine: 8.1%
      cubic: 5.2%
      spine: 5.0%
    • Feb 13 2014 | 12:11 pm
    • Feb 14 2014 | 1:58 pm
      I think I need to mention that nowhere is it said that gen~ operators are supposed to be identical to MSP objects. Though they may be inspired by them, they are developed independently. Moreover the domains are different, and making direct portability between MSP is just not possible in general. Though this is less obvious for delay/delay~, the probable uses for gen delay is different than the probable uses for (signal driven) msp delay~; the gen delay also needs to serve purposes of tapin~/tapout~, as well as IIR filters and physical models that are not possible in MSP. We chose linear interpolation as a default for gen delay as it is the most widely used type of interpolation across all these applications.
      I will make a feature request to add delay~-like interpolation as an option in gen; but it will not become the default.
    • Feb 14 2014 | 4:28 pm
      Thank you Graham!
    • Feb 28 2014 | 5:55 pm
      I just found out that, in my monophonic-extreme-pitchshifter for violin, none of the actual gen interpolations can really give me a clean un-aliased sound, I only get a clean sound using the sinc interpolation… in delay~!
      So yes I’m looking forward for a sinc interpolation in delay in gen!