Panning for Granular Gold in the Package Manager

    In my last journey through the riches to be found in Max's Package Manager, we took a look at one of my favorite packages, ODOT. This time around exploring Package Manager offerings, I’ll be taking a different angle by sharing a number of tools across the Package Manager for the same goal — granular synthesis.


    The grainflow package by Christopher Poovey is based around a sample-accurate, multichannel gen~ abstraction called grainflow~.
    The package boasts a number of tutorials, examples, abstractions, utilities, and impressive jsui interfaces. Just after opening up the launch patch of the package, you can try out a set of full-featured and musical examples like harmonizers, chorus effects, and granular samplers.
    With abilities to granulate both live and recorded input, the grainflow~ abstraction is a flexible and powerful granulation tool to check out. Also, as the only gen~-based granulator on this list, grainflow~ allows the adventurous Max user to dig in and see exactly how the DSP works!

    MuBu for Max

    MuBu for Max is developed by the ISMM team at IRCAM. This package is, well, packed with enormous possibilities. The overview describes the package as “a toolbox for multimodal analysis of sound and motion, interactive sound synthesis and machine learning,” and you could easily spend years just exploring the tools it provides for creative synthesis (like noise and concatenative synthesis), machine learning and gestural analysis, and audio and sensor analysis.
    Since this package is so deep, it’s easy to miss a fantastic granular synthesis object hidden in the creative synthesis section, mubu.granular~ (and its MC counterpart, mc.mubu.granular~).
    With the imubu object (displaying the waveform in the patcher shown above), the MuBu granular synthesis object is another granular tool that has a powerful user interface available.

    petra by

    The petra package by contains a set of polyphonic granular tools for both live and recorded audio.
    With many adjustable delay parameters, randomization abilities, and real-time manipulation, these objects let you granulate with flexibility. The documentation available in the package about the techniques used for DSP and memory management are a great resource that you shouldn’t miss out on if you’re interested in the little details that make this package special.


    The last object I’ll share in this article is one that is a bit of a “hidden gem”. The PeRColate package by Dan Trueman and Luke DuBois is primarily a set of physical modeling objects based on the Synthesis ToolKit (STK) by Perry Cook and Gary P. Scavone, but it contains much more! With over 70 objects, the package also contains effects like reverbs and choruses, wavetable generators, and assorted utilities.
    Inside the effects section, there’s a powerful stereo granulator and pitch shifter object, munger~, which granulates live audio inputs. My personal favorite ways of playing with munger~ involve turning up the density and randomness and mangling sounds into huge grain clouds. As of the PeRColate 1.3.0 release, you can also take advantage of the new MC version of munger~ – aptly named mc.munger~.

    There’s always more!

    Of course, there are granular synthesis tools not listed in this quick dive into the Package Manager. What are your other favorite tools for grainy goodness that Maxers should check out? Share below in the comments!

    • Aug 19 2021 | 6:19 pm
      Thanks for this great overview of the various granular tools. I was so excited about the different possibilities back at the release of the petra package that I built a Max for Live interface around the [cm.buffercloud] that tries to include all parameters (including the great multi-pitchshift) in a user-friendly way.
    • Aug 21 2021 | 7:25 pm
      Hello, short but really interesting article. I have an issue with munger~. The "delaylength_ms $1" should set the buffer length for the grain terrain, but I always get the same message in the console "munger~: setting delaylength to: 2.802187 seconds", with any ms setting. Audiotionig the actual result confirms that the real delay is 3 seconds. It can be set shorter, but not longer, and in any case the message alway declare 2.802187 seconds. Any clue on how to extend delay time?
    • Aug 23 2021 | 12:38 pm
      Hi Antonio! I've opened GitHub issue with what you've noticed. (
      How did you measure that the real delay time was 3 seconds? There is a set maximum delay time for the object, and my suspicion is that the console is mistakenly displaying the maximum delay rather than the actual delay. I'll have to investigate further to be sure.
    • Aug 23 2021 | 5:53 pm
      HelloIsabel, thanks for your answer. I used a metro to measure the last grain out timing. Even if it's not absoltely precise as a grain can start at the very end of the 2.802187 seconds and has some duration, I got the same delay with any delay setting longer than 3 seconds, that is the point. I.e. with 10000 delay time, anyway the last grain is sent out about at 3 seconds. Reversely shorter delay time is reportedly wrong on the console (always 2.802187), but actually works as expected. I was first thinking of an issue related to vector size, but seems not the case.