Another question about the delay node

Build
1

Hey it‘s me again … with another thing I don’t quite uderstand about the delay node :grin: (and that might be a bug)

When the delay time is set to a realy low value (a value betwen 0 and 0.00002248) not all of the input signal come out.

After 22.6757 seconds, which is the maximal delay length (1 000 000 samples), the rest of the signal comes out.

So If you put the signal from a trigger node throrgh a delay with feedback set to 0, mix set to 1 and time set to a value like 0.00002 only 0.875 come though and 0.125 come out after the 22.6757 seconds.

The lower the time value, the lower the value that comes out directly and the greater the value that comes out after the 22.6757 seconds.

I guess this is some kind of sampling problem too, since it becomes noticable with a time value lower than 0.00002248, witch is pretty close to 0.0000226757 seconds (which is the length of one sample)

Here is a little patch to reproduce the (maybe) bug:
Delay nodes .audulus (8.4 KB)

2

This is definitely due to some artifact of sampling and not a bug - why are you running into this in your patch building? Is it causing problems for you? If you need single sample delays you can use the UnitDelay node - it now works in feed forward configuration.

3

Thanks for your quick reply.

I ran into it while experimenting with the idea of adding a controlled delay in the feedback of of two (or more) PM Osciltors modulating each other.

PM feedback controll.audulus (68.4 KB)

when playing notes in octaves higher than -1 the delaytime will often be set to a realy low value and a lot of audio comes out again delaied by 22.6757 seconds which dosn‘t sound that good as a as a modulation signal :smile:

This thing is only problematic for this particular idee so its not that big of a problem.

I guess the workaround for other things build with delays would just be to make shure that the delaytime never goes under the length of one sample.

1 Like
4

That’s actually pretty interesting. I would love an explanation of that artifact.

32%20PM
32%20PM982×465 49.6 KB

Probably 2 samples, no? The Nyquist frequency seems like it should apply here. Anyways, that sounds like you need a clamp expression:

clamp( delaytime, (2/samplerate), ( (1e+6)/samplerate ) )

2 Likes
5

The „artifact“ only occured with delaytimes under the length of one sample so I think keeping it above the length of one sample is enougth.

(Thanks for the expression :grin:)

2 Likes