Hey folks.

Here's a polyphonic granular playback (and sampling) patch, I've been working on it for a while, I've used some different versions of it for a few different projects like the EN-1 video I posted last week. Full patches here: https://github.com/yannseznec/Granular-Polyphonic

It's currently 8 voice polyphonic, and uses 8 grains. These could both be raised significantly on any standard computer, I've kept them low for running on low-spec boards. It currently uses MIDI note input to play, with the note values controlling pitch. All other settings are controlled via UI sliders.

It's getting to a pretty decent point now, where it's relatively flexible...my long-term goal has been to make it somewhat drag-and-droppable.

It still needs work, of course! A few things I'd like to get some feedback on, if anyone has the energy to download all of the patches and have a play:

• At certain pitch values (particularly low ones) there is a fair amount of high frequency noise. I guess this is aliasing? I've tried to use the lop~ object to filter this out but it hasn't proven to be a satisfying solution. Any tips? I can just about understand why it's happening, with all of the fast phasors going on and the repitching of a sound file and so on, but it's still somewhat frustrating.
• Does the patch generally make sense? Any glaring mistakes?
• Any ideas for how you would use a patch like this, which could lead to different features, UI elements, or approaches to a hardware build?

In any case, enjoy! Hope you like it.

Hey @yannseznec,

i had a quick look at your patch. I have a few suggestions:
why don't you use line~ instead of phasor~?
Using threshold~ to trigger new events will definitely cause a some problems, especially when the grains are played at a fast rate!
Use switch~ to turn dsp of when the grains are not played and save some cpu!
And use the right inlet of tabread4~ to onset into table instead of adding to the signal. (see help ->browser->Pure Data/Audio Examples/B15-tabread4~-onset)

I have a granular sampler "pp.grainer~" in my repo if you want to have a look at it. Shared the link a while ago here https://forum.pdpatchrepo.info/topic/11906/audiolab

@solipp amazing! I'll try some of these suggestions.

why would you use line~ instead of phasor~ to play the grains? I don't understand the benefit, wouldn't you just constantly need to be triggering it?

similarly, I assumed that using a signal rate method for offsetting the table playback would be better practice than using the right inlet on tabread4~. I guess I was mistaken? are there benefits that I'm not considering? I rather like using a +~ object to do it but maybe I'm just stuck in my ways!

I tried using switch~ but found it made a click every time it turned the sub patches on and off. however perhaps that was due to something else entirely, so I should have another look.

I'm definitely not very pleased with my threshold~ solution, as you say it only really works well when the grains are relatively long. I'm looking for some method of changing the randomised values only when the grain playback is at the very beginning of each phase, to avoid clicking. I couldn't figure out a good way of doing that!

I'll definitely be having a look at your patches. Thanks so much for having a look and giving these ideas!

@yannseznec Yes, switch will cause a click, but you can take the output of the patch down first and bring it back up after with a [line~]
It has a side effect that any [readsf~] playback is paused, and a delay line like [delwrite~] is frozen.
David.

@yannseznec Thanks for sharing your patch.
I have made a granular sampler with vline~ which you might find interesting. The point of using vline~ instead of phasor~ is that this way the grain stream can be set as synchronous or asynchronous, or grains can be even triggered manually. It has 8 voices and 500 maximum grains per voice, but this is completely arbitrary. Also the way I'm using switch doesn't produce any clicks that I can hear, and it's used to turn on and off individual grains as well as whole unused voices. The grain window as well as other bits and pieces were taken from a granular delay called grannie basher that was posted in the forum years ago.
graindeurv1.0.zip
Main patch is graindeur-help.pd
I hope I have included all the abstractions needed, please let me know if something's missing. It requires the bsaylor external for the envelope.

I have also included your piano sample, hope you don't mind!

@yannseznec
one benefit of using line~ instead of phasor~ is that it allows you to trigger the grains rhythmically or to have gaps between the grains. Also, with line~ you don't have to use a workaround like threshold~

"similarly, I assumed that using a signal rate method for offsetting the table playback would be better practice than using the right inlet on tabread4~"

not in this case. you'll get some distortion at the end of a longer table (more than 32k samples) It's documented in B15-tabread4~-onset.pd

You should not get clicks with [switch~] when you do the windowing of your grains right.

cheers!

ok this is all super interesting!

it sounds like I got a bit enamoured with my phasor~ technique. I suppose I liked the idea of everything being at signal rate as much as possible, but clearly I should try a different approach!

time to start work on v2

@weightless

Thanks so much for all the tips and for sharing the patch! I'll definitely have a look.

@weightless said:

I have also included your piano sample, hope you don't mind!

you can pay any royalties to my two year old

@whale-av said:

@yannseznec Yes, switch will cause a click, but you can take the output of the patch down first and bring it back up after with a [line~]
It has a side effect that any [readsf~] playback is paused, and a delay line like [delwrite~] is frozen.
David.

ah yes of course, this makes sense!

@solipp said:

@yannseznec
one benefit of using line~ instead of phasor~ is that it allows you to trigger the grains rhythmically or to have gaps between the grains. Also, with line~ you don't have to use a workaround like threshold~

"similarly, I assumed that using a signal rate method for offsetting the table playback would be better practice than using the right inlet on tabread4~"

not in this case. you'll get some distortion and the end of a longer table (more than 32k samples) It's documented in B15-tabread4~-onset.pd

You should not get clicks with [switch~] when you do the windowing of your grains right.

cheers!

ok that's all super interesting! I guess I still see a downside in terms of needing to trigger the line~ envelopes using a (non-signal rate) bang, but is that not really an issue in practice?

thanks so much, this is all so helpful.

@yannseznec said:

I guess I still see a downside in terms of needing to trigger the line~ envelopes using a (non-signal rate) bang, but is that not really an issue in practice?

Why? Usually you won't change any parameters while a single grain is playing. So instead of sampling a signal with [samphold~] you can just keep everything in the control domain and save some cpu.
If you want to trigger your grains with sample accuracy use [vline~] instead of [line~].

Just wanted to pop back here to say thanks! @solipp @whale-av @weightless
I've finally managed to get back to this patch and try out some of the techniques you all mentioned (namely using line~ and the offset system in tabread4~) and it's sounding much better and it has opened up a few new sonic possibilities. I'll post updated patches soon!