Passively, it uses a bunch of
fluid.bufcompose~ (as well as some HIRT stuff (
irtrimnorm~)) under the hood to improve how the grains are captured/stored/sized/etc… but the big improvement is that it now uses
fluid.buftransients~ to “three way” decompose the audio, and then lets you control the balance between these components.
It’s also packaged up as an M4L device, so all the dependencies are packed up together nicely.
http://rodrigoconstanzo.com/party/cloudv2.1.zip (edit: changed to latest version)
I still need to go through and clean up the code, as well as bundle in the Windows versions of the externals, but I wanted to share the code/sound, and get some thoughts on interface.
It’s kind of a tricky thing to explain, so I’ve wrapped up all the complexity into a single “timbre” knob. So at 50%, everything is active and the sound is “normal”. At 0%, it’s only the harmonic component, and at 100% it’s only the transient component (with a crossfade happening at around 90%).
In context I think this sounds really good, as you can push the granularization more into the “background” by pulling away the sharper transients. Similarly, you can really crank up the invasiveness of it. My initial build of this only used HPSS, since I thought that pure transients would be too much, but I decided to go “three way” with it today, and just adjust the scaling so that you only get 100% transients at the very extreme of the “timbre” knob range.
I’ve also used an adapted version of my C-C-Combine grain playback module, which has the ability to change grain window type. I’ve included that here, but I don’t know how useful this is across the range of possible settings. (i.e. the more you turn the “timbre” knob up, the ‘shorter’ the grain sound via the decomposition, and hence the window types make a smaller impact). Open to suggestions on this.
UI is also utilitarian and bare bones for now too.