< Back to IRCAM Forum

Great granular player ! A few suggestions

Hello,

Altought I played a bit with the beta versions before, I’ve just realized how good mubu-granular sounds. It’s the best granular engine I’ve ever heard, both in terms of sound quality and flexibility !

A few suggestions to improve it further :

  • allow for a larger transposition range (what sounds like transposition to my ears is the parameter named “resampling” - I don’t understand the function of the parameter named “transposition” for actual transposition). While I have used the “maxresampling” message with a number higher than 2400, mubu-granular won’t transpose beyond 2 octaves both up and down - this is the single point where other granulators do better ;

  • let the resampling affect the grains already playing and not only the new grains (not a problem with tiny pitch variation but quite annoying when going from a big slowdown to a much higher speed because one can hear the older grains still playing with their low pitches);

  • offer an option to set the playback position as the beginning of the grain rather than as its middle ;

  • when the playback position is at the end of a buffer, one can hear the sound of the beginning of the buffer (as if it was a circular buffer). Allow for alternative behaviors : either fold playback position when it overrides buffer length, shorten grains or limit playback position according to grain length ;

Best regards,

Roald Baudoux

 

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.

Hello Norbert,

Thank you for the explanations, almost everything is now clear. However one point still remains obscure: to me setting the @cyclic attribute means to have a continuous playback but does it automatically imply that when reaching the end of sound source, mubu-granular fetches the missing sound at the beginning of the sound source ? Otherwise if @cyclic only implies this and not the continuous playback, how does one get that continuous playback but without that “warping” ?

Best regards,

Roald

In fact, at some point in the development of the underlying engine those two things, warping the audio buffer and treating the position % duration, was two options. Since I ended up setting always to the same value, I finally united them into a single option.

In which case, you think, it is useful to separate them?

After all, “continuous playback” depends on both, one makes that your grains won’t be shortened and the other that you jump from the beginning to the end.

What actually happens to non-warped grains that exceed the range of the buffer is that they are zero padded and not shortened.

That implies that the calculated grain duration and window does actually not change at the limits of the buffer. That very much simplifies the engine and permits more easily to keep the precision concerning the grain position etc.

Maybe if you see it from this point of view – a sound file that infinitely continuous with zeros before the start and after the end if you don’t warp it – those two warps, samples and grain position, are actually the same…