Grain size parameter of e_graindelread ‘inverts’ depending on value of grain-rate parameter

[jamiebullock]

Steps to reproduce:

• Set the grain-rate parameter of e_graindelread to some low value, e.g. 4
• Set the value of the size parameter to 500
• Gradually change the value of the size parameter from 500 down to zero

Expected behaviour:

• The grain size gradually decreases until it reaches zero

Actual behaviour:

• The grain size decreases, but then starts increasing again at around size == 250!

[footils]

Hi Jamie,

puh, thanks a lot for pointing this out - that's a tricky one to fix. Actually I believe, the problem is, that the grain size parameter is not controlling grain size at all, it's controlling a variable delay inside which results in pitch shifting! You can see this if you use a sine wave as input, say [osc~ 440], then set the parameters to something like:

pan-r 0, delay-r 0, delay 0, size-r 0, size 0, vol-r 0,
vol 1, bw 1, grain-rate 1,

This will give a slow sinewave pulsing at 440 Hz. If you now increase the grain-size, the sine pulse will lower its pitch, but the basic rhythm will not change.

I'd rather not change to abstraction itself, for reasons of backwards compatibility. Maybe I can get away with fixing the documentation, adding a better name for the grain-size controls and deprecate with use of the grain-size parameter name (but still supporting it). What do you think?

All the best.

Frank Barknecht

[jamiebullock]

Hi Frank,

Yes, I did think the parameter naming was not quite right, so changing that is a good idea.

However, I still don't understand why there is this "inverting" behaviour when the grain-size parameter is modulated. Using your sine tone example, if you set the grain-rate to something like 4, and then gradually decrease the grain-size parameter from 500 downwards, it will fall in pitch, and then at around 250, start to rise in pitch again! Do you know why this is?

For our purposes, we are using e_graindelread in our GranularDelay module in Integra Live. Changing the parameter names is fine, but it would also be good if we could "fix" this inversion behaviour, so changing "grain-size" (or grain-pitch?) causes a linear rise in pitch from 0 to N.

Do you think you could suggest such a fix? Maybe as an attachment to this issue thread...

All best,

Jamie

[footils]

Hi Jamie,

okay, I have researched the issue a bit deeper now.

I believe, the problem is that grain-rate and grain-size are both influencing the resulting transposition. In the graindelread abstraction however both can be specified independently. I made a patch illustrating this, which you can download at this Gist location: https://gist.github.com/footils/5546707

The momentary transposition factor t according to Miller's book is calculated as:

t = 1 - s*f/R

where s is the grain size and f the grain rate, R is samplerate. In the example patch, you can specify s as a percentage of f/R, the phasor's period. At s = 0% you get a transposition factor of 1, which is the original pitch. Raising s to 50% gives a transposition factor of 0.5, i.e. half the original pitch.

s = 100% will make t = 0, so no pitch at all: silence. After that, the transposition factor becomes negative, which will make the signal's perceived pitch rise again. I must admit that I don't fully understand yet, why this is so - I guess it has something to do with foldover, or maybe it's, because the delay line tries to read into the future - or the past?

Anyway, I don't really think, that I can "fix" this inside e_graindelread without changing the interface of the abstraction. If a certain transposition for grains is needed, one should probably fix either s or f and then change the other parameter accordingly. Maybe you can do this in Integra with some parameter wrangling?

All the best,
Frank

Here's the patch as screenshot, if image uploading works:

[jamiebullock]

Hi Frank,

I really appreciate the comprehensive answer, and the time you have taken to look into this.

In terms of fixing this for Integra Live — yes, I think your suggestion of wrangling parameters is a good one. We can probably change the interface of our Granular Delay such that it is impossible to reproduce the "parameter inversion" behaviour.

best,

Jamie