OK, here's a basic live input granulator, no really fancy features, just pitch shifting.

The handling of grain playback rate in the one-grain abstraction is a neat trick I had worked out some time ago. For example, if you want to play the grain an octave higher (2x speed), then you need to span 2 * dur ms of audio in dur ms of time. You can do that by modulating the delay time as a straight line, from dur ms to 0 ms -- adding dur to the delay time at the beginning adds that many ms to the amount of audio being used: dur * (rate-1). Or, to play slower, start with a shorter delay and go toward a longer delay, and the boundary is again dur * (rate-1). If rate = 1, then the delay time goes from 0 to 0 = no change = normal speed. That might look a bit funky in the patch you can try it with different transposition intervals, which will show that it's correct.

For sound file processing, replace the delay line with a soundfiler-filled array, and use tabread4~ for the audio source (and the line~ driving it will have to be different too).

IMO granular processing is 99% refinement and more advanced modulation of these basic parameters, which you should be able to tailor to your needs. I think the pitch shifting is more-or-less smooth here, though I'm not sure it matches your comparison plugins -- this is 66.6667 grains per second, with 4x overlap.

one-delay-grain.pd
live-granular.pd

hjh

@Moddmo said:

I don't want to spend months making a patch and end up with crap sound.

Well, that's hard to promise because I'm not sure exactly what you mean by crap sound.

What I can say is that granular synthesis is made up of short clips of audio under envelopes. Pd can do both:

• clips: tabread4~ for a sound file loaded into memory, delread4~ for live input.
• envelopes: you can fill an array with a Hann (or any other type of) window, and stream it out using tabread4~ as well.

Pd has one edge over Max here, in that Pd's metro is sub-block accurate. In both Pd and Max, there's an audio block size (default 64 samples), and control messages execute only on those block boundaries. In Max, last time I tried to do granular synthesis driven by control messages, I could hear the timing inaccuracy due to the messages being quantized to these block boundaries. (Maybe that's changed in Max 9, but that's my recollection from Max 8.) In Pd, control messages are processed on block boundaries, but they also carry sub-block timing information so that grains will start on the right sample, not just the right block. IMO Pd's timing was noticeably smoother. (In Max, multichannel signals get a better result.)

For sound quality, it's very helpful to introduce a little bit of randomness into the grain time position, to avoid "machine gun" effects.

Again, "close to the available software," I'm not sure exactly what you mean. With proper tuning, I was able to get a pretty smooth sound out of it. Maybe an example later.

hjh

I'm having fun with granular processing of samples and live input of acoustic instruments.and I'm thinking about making a granular processor in pd.

I've tried several granular apps and software (I love Grainstorm on Android) but I keep seeing interesting possibilities that none have implemented, especially for live manipulation.

I don't want to spend months making a patch and end up with crap sound. Would I be able to make granular patches with sound quality at least close to the available granular software? I have a good grasp of pd/Max. Any tricks/pitfalls you can think of (besides declicking)? Thanks!

@nicnut Yes, as the [phasor~] output jumps it could output samples that jump from near 0 to near 1 or vice versa and that will produce clicks.
You could window each grain, or as I did here soft duck the output during the jump.
The effect is the same I think.
Microsound-granular.pd
See [s smooth] and [r smooth] for the duck.
David.

Hi everyone,
I’m currently working on a small granular patch and trying to make it properly stereo.

Right now I have two separate arrays — samplebufL and samplebufR — and two corresponding tabread4~ objects that feed throw~ busL and throw~ busR.
However, I still only hear sound from the left channel.

granular2.pd grainvoice.pd

It seems that both tabread4~ objects are not being driven independently, or maybe my right buffer isn’t being read correctly.

I’ve attached the two files:

granular2.pd (main patch)

grainvoice.pd (the subpatch that handles each grain)

Could someone please take a look and tell me what’s missing to make the granulator output true stereo?

Any help or advice on the best structure for a stereo granular patch in Pd would be greatly appreciated!

Thanks a lot in advance 🙏
Emiliano

If you have a working granular buffer player with phasor~, a non-looping version would delete the phasor and replace it with a line generator.

The phasor~ already normalizes the position within the buffer to the range 0 = beginning, 1 = end. The granular player then should already include the objects to convert that into a sample position. So as a starting point, your line~ / vline~ can simply go 0 to 1 and plug into the same normalized --> sample index logic. There may be some other refinements later, but start there.

hjh

you need four buffers and you need to record audio into it. that's not tricky. the tricky thing here would be overdubbing the same buffer, which may imply some form of summing of your output audio with your input audio, for each of the buffers. even though i would like to point you to a couple things in here: one would be, and is effecively to use a tape delay with 8 and 40 seconds. the other is using a granular delay line. and finally to use granular synthesis with less voices, very large buffers, very large grains, and so.
cheers

@nicnut This might be useful...... it's the old help file from Pd extended and includes at least reversing an array...... all_about_arrays.pd
But an array is indexed...... so can be played backwards anyway by counting down instead of up.
You need the total size of the array (so as to preserve the pitch) and then you can use [phasor~] if you want repeats, or [line~] if you don't, to play parts or all of the array in both directions.
You just need to calculate the range according to the total size of the array.
Here is an old attempt using [phasor~]....... Microsound-granular.pd
It is all just maths...
David.

The use case is a granular synth similar to these ones:

Respectively, there is only one sample, but played simultaneously at different positions and with different speed etc. At the moment I'm using multiple sampler instances each with its own array and read by its own tabread4~ object. The granular synth abstraction is used in several patches and I'd like to declare a subfolder for the sample used in the cloned sampler instances in order keep everything structured and clean. But yes, a great idea to use only one array and pass it to all sampler instances! I'll definitively try it out. Thank you!

Hallo everybody,
I'm a newbie with PD and I need some help.

I downloaded a live granulator patch. I'd like to add some "gate" on the input in order to make the patch work only after a certain mic threshold - because it will be a sort of installation.

I used "moses" and it makes what it should, but don't change the volume of the input (to 0).
I think it's related to the hot/cold inlets, but I didn't find any solution.

Could you please help me?
Thank you

3-7-2-1-granular-live.pd