Why not three fader?
Yeah I get that. In this case it was just a practical improvement to an existing effect/idea, but for other things that more fully explore that, I will probably do something more comprehensive (though still wrapped in a mapping metaphor of some kind). (i.e. if I have my sample buffers automatically NMF in the background, having some kind of interface that lets you play with the balance of those)
Perhaps a different fade curve? At the moment it’s all linear with both being 100% when you have it set to 50%, and then fading down from there.
I have adjusted my grain window amplitude compensations now, since the cloud stuff was always too loud as compared to the dry. I think the multipliers I came up with work well when the grains are all really tiny, but for these bigger pieces, it’s too much.
Interesting. Totally possible (though I just stripped out the per-grain amplitude adjustment stuff, to save a few *~s. The way I viewed it is that was sort of “built in” as what you record into the rolling ‘granularization’ buffer is anything (that triggers the onset detection algorithm).
Something like this would well in an ‘advanced’ tab or something. And it could be interesting, but I don’t want to over complicate the vanilla version. Hell, most of the parameters could be rslider-esque controls (or even more hardcore with @a.harker’s randomvals options for each parameter).
Hmm, I can maybe add a small amount of random variance in grain volume as an always-on feature, just to give it a bit of shape. Or tie it to activity and/or pitch.
Hmm. At the moment it’s fixed at 1000ms, which gives between ~6-30 “grains” from the “past”, with the current analysis/processing settings. I’ve found that that works pretty well for morphing with you, but also not having too much “latency” when you want to change.
A very “PA” take on this would be to have your normal “record everything that has ever happened” buffer, which you can then (manually) select a window from to be available for “Cloud”-ing. (either as a static/absolute, or relative/rolling selection (i.e. the last 2s of time, or this specific 2s of time)
It’s super brutalist. Each grain is panned hard left/right randomly (at the time of grain creation) then the width parameter just “pans” that towards the center or full width. It’s “fixed”, so you don’t get an overall granular spread of panning, but it still works well in terms of giving you some width/shimmer along with your dry audio.
(the effect also sums to mono before recording, even though the thru is left as stereo. I didn’t want to manage two of everything, or have a double CPU hit, and given there’s already panning involved, the mono->stereo grain thing works well)
I’ll take a look at the scaling, as I did that back when I first made the effect. More than anything it controls how many grains will happen after each onset is detected, but I think it also effects other things.
Of course!
Obviously not until the library is released.
Part of this effort, beyond making some of the effects I use often more compartmentalized and easier to reuse (literally dragging in a single .amxd, instead of finding all the abstractions/dependencies), is I want my FluCoMa performance patch to be very legible and dissectible. So I want the core items to be abstracted like this. (I’ll probably post my waveshaper on here too, even though it doesn’t (presently!) use any FluCoMa stuff, as I’m curious as to people’s thoughts)
It’s a shame you don’t use Max8, as they introduced an object called sfrecord~ that you may find very useful 