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!

@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

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

this has a bunch of stuff it uses an older version of pd sometimes but you can work around it , they changed a couple object names.
http://pd-tutorial.com/
http://pd-tutorial.com/english/ch03s07.html

@Moddmo Try this vanilla (no deps, I think) patch by:

Granular21 patch by Jakob Skouborg 3.2.21

I run the patch at 48khz, but you should be able to run it at any sample rate.
The sample that comes with the patch in the ´+Sounds+ folder is 48khz!!!!
So if you want to run it at 44.1khz, you need to convert the sample!!!!

granular21.zip

@ddw_music

Thank you! I will play around with this.

And fair enough, crap vs. quality sound is subjective. I guess a better question is if pd has disadvantages here compared to other DSP programming languages.