-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Grain size parameter of e_graindelread ‘inverts’ depending on value of grain-rate parameter #16
Comments
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, 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 |
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 |
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, Here's the patch as screenshot, if image uploading works: |
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 |
Steps to reproduce:
Expected behaviour:
Actual behaviour:
The text was updated successfully, but these errors were encountered: