Hey team, this granulator is lit especiually the part with filtering grains :)))
But as for anby tools which is awesome and very customizable, it makes me wish it were even more customizable and awesome, essentially by adding the possiblity to pass parameter value lists instead of one float/enumerable.
This would be especially cool for the playback speeed param and the filter type param : for the first param, i would like to be able to send a precise set of playback speeds ; in which one different speed would be selected (randomly) for each grain. As for the filter type : there is already the Random type which i like a lot, but i would love to be able to send a list with for exemple BandPass and LowPass but not AllPass or HighShelf.
Maybe there is a cpu efficient way of doing that which i do’nt know of already, since the controls are using a osc format ? but this little wonderful piece is already heavy on computer so i am reluctant to send control param changes at the speed of light…
Thansk in advance !
Hello vichug,
This is an interesting feature request.
What would you think of the proposed syntax below (which obviously adds some complexity, but allows more flexibility – while being backward compatible) ?
[see attached screenshot]
(similar syntax would apply to other random parameters)
Best,
T.
Hey ! This looks really nice, but i wonder if the /speed/mode is not an avoidable overhead : it could be possible to infer which mode we are in, by only allowing the last received parameter to affect the speed. If this inference is not done automatically, there could arise annoying cases whence we wonder why affecting the speed parameter doesn’t work, and it would be because we pass a speed/range when the mode is set to enum, for instance.
I think it would not affect the backward coimpatibility ? as sending nothing more than the speed/variation would’nt change stuff ?
Alternatively it could be a choice to allow cumulative speed modes : for instance you pass a list with enum, and allow a little variation on those enumerated ( this is beginnning to be a gas factory %) )
Hello vichug,
I agree that adding more parameters inevitably turns the things into a gas factory.
Greater power to the user also means greater responsibility.
You asked for it !
However, I believe it is straightforward to avoid misuses. Just send the /speed/mode message along with each change of parameter (see attached screenshot). The computational overhead of sending lots of /speed/mode messages is negligible; and it is likely that the control parameters will be wrapped into a UI abstraction or whatever, so the added complexity is actually hidden to the end user.
(in other words, I’m not super enthusiastic about the automatic inference you suggested)
Let us know what you think.
Best,
T.
Hey, thanks a lot, indeed i’m the one to ask and whatever solution you think is better, is the solution i’ll use and wrap my head around :))
i’m curious however why is it that you don’t think this automatic inference is a good idea ? i don’t see the advantages of having this /speed/mode parameter existing at all, only think of possible misuse cases, and don’t see where those misuses could happen with the automatic inference ?