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

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.