# HPSS/Transients-sliced "realtime" granularization

**URL:** <https://discourse.flucoma.org/t/hpss-transients-sliced-realtime-granularization/339>\
**Category:** Code Sharing\
**Created:** [October 31, 2019, 12:29pm UTC](https://discourse.flucoma.org/t/hpss-transients-sliced-realtime-granularization/339 "2019-10-31T12:29:17Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)\
**Post date:** [November 1, 2019, 10:23am UTC](https://discourse.flucoma.org/t/hpss-transients-sliced-realtime-granularization/339/10 "2019-11-01T10:23:16Z")

</div>

> [@tremblap](#):
>
> your mapping works well because of your material (percussive, decaying) and your playback (granulation is very transient sensitive - it betrays the process) but other types of material probably would benefit from a 2 fader approach

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)

> [@tremblap](#):
>
> I miss a volume control - the blend is never satisfying for me since I might want something else than a cross fade

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.

> [@tremblap](#):
>
> it would also be good to have a volume variation control like the pitch one

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.

> [@tremblap](#):
>
> I miss a ‘size of the past’ button (do I want to keep 1s or 10s or 100s or 10ms as my grain pool)

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)

> [@tremblap](#):
>
> the width is great. You dig a whole in the middle, right? 50 is full-stereo range, and higher digs the middle?

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)

> [@tremblap](#):
>
> I think activity could go wilder, like much denser, but again this is your implementation, which has limited overlap, and is very ‘Rod’ sounding. I love it a lot

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.

> [@tremblap](#):
>
> Do you plan to distribute the code opened too?

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)

> [@tremblap](#):
>
> I tried to record the output of this demo, but I don’t have the screencapture with pro audio software on my machine. I still recommend this highly:

It’s a shame you don’t use Max8, as they introduced an object called `sfrecord~` that you may find very useful 😛

---

_[View the full topic](https://discourse.flucoma.org/t/hpss-transients-sliced-realtime-granularization/339)._