Here is an interactive learning patch that decomposes drum loops to be used in a simple granulator.
Any and all feedback and suggestions on developing the patch would be appreciated!
(make sure you download both files)
harmonicDrumGranular.maxpat (61.5 KB)
drum.grains.maxpat (16.4 KB)
This sounds quite cool.
I actually like what the strip-silence step does to the “groove” of it.
It would be interesting to perhaps fork each component down its own tree/path, and then create a macro-granularization that incorporates all of them (different rates/panning/etc…). Particularly since, at least with this example, “time” is getting erased and we just have a “cloud”-type sound.
Also reminds me a bit of something @spluta was working on a while back doing an epic multi-resolution version of PaulStretch that is, somewhat conceptually, similar (to what I’m suggesting at least).
p.s. loving seeing some new examples on here!
Thanks for the feedback! I’ve had a go at implementing some of those ideas, let me know what you think.
drum.grains.maxpat (34.0 KB)
harmonicDrumGranular.maxpat (141.6 KB)
Very cool, dig the additions.
You can also add in a step that pre-sorts the components, so they don’t end up in a random order.
In the patch I posted here one of the steps takes the centroid for each channel of the bases and rewrites them to a new buffer based on that order, and I’ve found it to be quite effective. At minimum, it’s always consistent.
Awesome! I’ve implemented your ordering idea.
Doing so has allowed me to label the components in the granular, making it substantially more user friendly when it comes to knowing which sound is linked to which parameter!
drum.grains.maxpat (34.5 KB)
harmonicDrumGranular.maxpat (153.6 KB)
Nice.
I do wonder why there isn’t a default sorting applied, or a @sort attribute since this will be such a point of confusion/faff to most coders (novice and advanced alike). I get that there’s no solid universal way to sort things (centroid makes sense for bases imo), but always getting a random order (unless you specifically seed things) makes it needlessly clunky.
This is especially the case since applying sorting requires getting into some gritty plumbing between the objects.
p.s. you don’t need the counter in your sortdrums subpatch. The b won’t trigger until after the l has done it’s thing, so something like this would work regardless of how many components you have (whereas the counter method would require you manually changing the cutoff point).
Thanks again!
I struggled to think of an immediate solution to that issue so I ended up needlessly overcomplicating things with the counter.
Here’s the full patch again with that quick fix!
drum.grains.maxpat (34.5 KB)
harmonicDrumGranular.maxpat (151.7 KB)
