Dear Roald,
Thank you very much for your suggestions and encouraging comments (in fact, we worked quite hard on many tiny details that make that all features are implemented with over-sample-accurate precision and even if the effect on the sound is extremely subtile for many settings it actually should make quite a difference in extreme settings and especially in synchronous mode).
Here are some answers and precisions concerning your points:
As you understood, the @maxresampling attribute is the maximum value of the @resampling attribute.
To increase the “absolute” maximum (defaulting to 2400) you have to give it as an attribute argument of the external (rather than setting it by a message). The help patch tries to explain this in the little box below on the right in the sub-patcher “general control”.
The message “transposition” actually affects the relative period and is together with “frequency” an alternative way of setting the values of the @period attribute. The reasoning in terms of transposition and frequency (rather than absolute and relative grain period) makes particularly sense for synchronous granluar synthesis, since here the perceived pitch does not depend on the original sound but the period of the granular engine that may or not coincide with the frequency of the original sound.
Affecting grains that are already started is difficult for mubu.granular~. Actually, the (“ZsaZsa”) synthesis engine on which the external is based synthesizes grains atomically (just as “Gabor” does in FTM & Co). For not having two many grains lingering behind (after all, down-pitched grains can become pretty long!), it would be good to shorten the duration as a function of the resampling so that the output grain duration is constant and not too long. I take this as a feature request for a message or mode in which the resampling value automatically affects the grain duration (always given in respect to the source sound) – i.e. a mode “keep-overlap-when-resampling” or “compensate-duration-for-resampling”. That is also good for keeping down the computation power.
The @centered attribute controls whether the grain position refers to the beginning or the center of the grain (default is @centered 1). Apparently this attribute didn’t make it into the help patch. Apologizes.
In the contrary, the @cyclic attribute made it into the help patch (…probably with a rather obscure explanation :-)). Anyway, it controls whether the source sound is considered as cyclic (as you describe it) or whether the grains are cut off at the beginning and end. What I don’t understand is why you have a cyclic behavior without knowing the @cyclic attribute, since the default value of 0 (“no”) is also the default setting in the help patch. Can you please verify that the @cyclic attribute works correctly for you?
In fact, I don’t like too much the idea of clipping automatically the grain into the range of the source sound. But if there are more voices for this feature (including you keeping asking for it :-)) I would certainly add it.
If you want to implement it outside the external don’t forget to also consider the random variations of duration and position.
Thanks again for the remarks
Norbert
P.S.: We have been promised email notifications for the Forum discussion groups, so that it can work almost like mailing-lists. I guess, this feature will come soon.