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.

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.

Up!

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

Thanks! Regards,

I don't know what was going on in your original patch but I'm getting the same output from each with this test:

@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

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.

here is right test patch to see the problem in case of doubt: (same as my first message)

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.

btw, what is the gen equivalent of the interpolation used in delay~ when controlling the delay time with signal floats ?

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.

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.

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

Thanks!

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%

Screenshot:

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.

Thank you Graham!

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! (see other topic i just made: https://cycling74.com/forums/feature-request-msps-delay-quality-much-higher-than-gens-delay/ )

Thanks!

Use [slide 1500 1500] (or shorter numbers) to feed through delay time values, that should get you rid of the clicks.