Polyphonic Granular patch, looking for some feedback/tips
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.
Fm Synth Mod Matrix Help
@LarsXI In the 3-op synth patch you mentioned there is an option the synch the phasors when you hit a new note, I don't know if that helps with what you are saying.
It's good to know that it's a little cheaper, anything helps as by the time you add polyphony things add up pretty quickly. I think that making a full-blown polyphonic 6-op synth with this method is pretty unrealistic, I think it's interesting to experiment with less operators and different waveforms. I did modify that 3-op synth with added waveforms like the TX81z, but then got carried away and added CZ-style oscillators too and that messed up the patch and I never had time to fix it.
I look forward to your 2-op patch, those camomile plugins you posted sound pretty sweet.
best practices, sample-accurate polyphonic envelope, note stealing
Hi everyone. I have frequently revised designs for polyphonic envelopes. i've often misunderstood things about vline~ and scheduling voices in such a way to avoid unwanted clicks while also keeping things on time and snappy.
i'd be really happy to know what your methods are for envelopes.
i submit this patch, a reflection on envelope practices and how i address certain challenges. envwork.pd
this patch makes these assertions:
1- because vline~ maintains sample accuracy by scheduling events for the next block, you can switch dsp on in a subpatch with block~ while sending a message to vline~ and the dsp will be active by the start of the vline~ output. This also works if you need to configure a non-signal inlet before triggering a voice. send a message to such an inlet concurrently with a vline~ message and the parameters will update on the block boundary before the vline~ plays.
2- accounting for note stealing can cause issues in a polyphonic patch. if the stealing note has a slow attack and the envelope of the stolen note is not closed, there will be a click as the pitch of the new note jumps. the voices in my patch apply slight portamento to smooth out this click. if, however, the attack time of the stealing note is faster than this slight portamento it is counterproductive and will soften the attack of stolen notes. Stolen notes need every bit of snap they can get because the envelopes may be starting at a non-zero value. so i limit the time of the portamento to the attack time.
3- to make sure a note that is still in its release phase is treated as a stolen note, it is necessary to monitor the state of the envelopes like so:

switching the dsp off too close to the end of the release causes clicks. after testing, my system liked a full 50ms of extra delay after the end of a release before it was safe to switch off dsp. I don't think this is attributable just to the scheduling delay of vline~ but it's a small mystery to me. possibly there's a problem with my voices.
This all gets a little more complex when there are multiple envelopes per voice. The release time that affects the final output of the voice must reset all envelopes to when it is finished and before dsp is switched off. Otherwise an envelope with a long release affecting something like filter frequency can be held at a non-zero value when dsp is switched off and spoil the starting state of the vline~ on a new note.
finally, on vline~ and sample accuracy and timing, let me type out what i believe is the case. i could be wrong about this. if you programmed a synth using line~ for the envelopes, it would be faster than vline~ but not all notes equally faster. all notes would sound at the block boundary. Notes arriving shortly after the last block boundary might take 90% of the block period to sound. notes arriving just before the block boundary might take 10% of the period to sound.
vline~ will always be delayed by 100% of the block boundary. but the events will be scheduled sample-accurately, so the vline~ will trigger at exactly the real time intervals of the input. a synth with line~ envelopes will trigger any two events within a single block at the same time.
this should mean that vline~ envelopes can be accurately delay compensated and stay absolutely true to input timing, in the case of something like a Camomile plugin.
however, if one was to build a synth for something like a raspberry pi that will act as hardware, would it be better to use line~ envelopes and gain a little bit of speed? is the restriction of locking envelopes to block boundaries perceptible under normal playing conditions?! i could test some midi input and see if the notes in a chord ever achieve a timing spread greater than the block period anyway...
[Solved] Several MidiNotes to several osc's
@Balwyn said:
If you were thinking of using [poly] to create a polyphonic [osc~] synth, you can do it this way
Balwijn Thanks you also much for your help! This is a clear picture and understandable to me how to continue my experiment with PureData!
Greeting Crojav
[Solved] Several MidiNotes to several osc's
If you were thinking of using [poly] to create a polyphonic [osc~] synth, you can do it this way

Which version for an absolute noob?
@CrouchingPython Pd has midi output...... and you could connect an external synth and select it from the Pd "Media" "Midi Settings".
But if it is a software synth on your computer then you need to loop-back the output of Pd to the input of the software synth.
In Windows you could use loopMIDI........... http://www.tobias-erichsen.de/software.html
Open it and set up a loop (there could well be one opened straight away by loopMIDI..... then open Pd and connect to it....... and open your software synth and connect to it.........
Widows10 might still have "Microsoft GS Wavetable Synth" still built in, but some say it doesn't work and Google will find you plenty of free and better ones.
The Arturia is a controller...... it outputs midi messages the same as Pd....... and still needs a synth (something to make the sounds when triggered by midi messages).....
David.
makenote not working libpd Android
@kevinzo22 Hi, [makenote] doesn't "make" sounds but it builds midi note messages from three numbers (midi note number, velocity value and note length in milliseconds).
If you do have midi messages already and want to make sounds from them you need some sort of synth/sampler, and the timbre of the sound depends on the synth itself so that's entirely up to you and what you want/need.
here is a simple sine wave polyphonic synth patch to get you started:
blip~.zip
(see blip~-help.pd)
prophet 3003 wavetable synth prototype
hi folks, thanks for the kind comments!
sure ill share the patch eventually but right now its an uncommented messy laboratory affair. best thing you can do right now is look at the patch image above which is quite self explanatory.
here is the vs rom in one wav file, scan this in 128 chunks of 128 samples and you have the single wave data.
harmonic aliasing is best described by acreil in the above mentioned blog post because thats where i got the idea from. the rest is trial and error and a lot of listening to integer combinations.
harmonic aliasing is actually my own term for what im trying to do. here is how i would describe it:
-
if you repeat 128 samples with a phasor at 128 hz (or 64/32/16/8/4/2) or any multiple of 128 your phasor restarts exactly at the beginning of the wave data and the aliasing frequencies generated by the steppyness of the data will follow the harmonic overtone series 1,2,3 etc. depending on the multiple.
-
if you introduce another prime divider ie. 3 as in 128 / 3 the phasor will line up with the sample data every 3rd sample and the osc will alias at the 3rd subharmonic frequency which will be somewhat more disharmonic than any overtone.
-
another way to look at it would be the pattern repetitions. at subdivision 5 the phasor starts at 5 different points in the sample data and its easy to imagine that the readout patterns are all slightly different ... but the whole thing cycles after 5 phasor rounds = 5th subharmonic..
-
if you subdivide 128 further with a higher prime ie. 563 you will get 562 different sounding samples until nr. 563 lines up again. get the idea?
this is all very easy to hear once you experiment with prime subdivisions and multiplications. just remember its all based on synching the data flow from the sample with the frequency of the index phasor. this will work with ANY sample data, the vs rom is just cool to use for vintage synth fans.
whats important for proper aliasing is that you use a simple [tabread] into the data without any interpolation like tabread4 or oversampling!
all the other elements in the synth like delay, waveshaper, sequencer follow the same rule as they are just repetition devices like the wavetable oscillator.
if you finally synch everything to the sample rate of your soundcard the voltages that hit your speakers will repeat in exact patterns. thats the idea of this synth: precision number repetition controlled by harmonic/disharmonic integer combinations ... just like the great 80s synths waldorf microwave or prophet vs.
prophet 3003 wavetable synth prototype
hi all ... im developing a funky wavetable synth thats inspired by the sequential circuits prophet 2000 from 1985. it uses the original 12 bit ROM from this synth and and a synthesis menthod called harmonic aliasing.
- all frequencies and repeat rates are related by simple integer relationships
- adaptive just intonation = infinite tuning systems
- 3 oscillators per voice
- wavetables by multiplexing oscs with waveshaped sines
- variable sample rate simulation via resampling with audiorate wavetables (BLITs)
- integrated complex numeric sequencer
- integrated delay for hardware mixer feedback loop with analog eqs
basically it includes everything i think is cool about numeric sequencing and is still really low on dsp because its all based on integers mechanics like early wavetable synths.
this synth can sound really ambient or real raw depending on the complexity of the number relationships and the waveshaping settings. eventually this is going to be a hardware synth with FPGA technology, variable sample rate per oscillator and analog eqs/filter ... just like in the 80s 
project logo:
https://i.imgur.com/F1kqrMt.png
prototype patch:
wave multiplexing:
.
harmonic aliasing is inspired by a patch by acreil: https://forum.pdpatchrepo.info/topic/6759/new-anti-aliasing-and-phase-distortion-abstractions.
early discussion: https://forum.pdpatchrepo.info/topic/11176/adaptive-sample-rate-and-harmonic-aliasing-in-pd
.
mixer delay feedback loop feature:
lots of different sounds with audiorate waveshaping:
.
Midi MPE
Polyphonic aftertouch doesn't really apply here. MPE is a re-adaption of the midi standard that distributes polyphonic notes across individual channels so that any controller/pitch/whatever channel parameter only affects that single note.
https://www.midi.org/articles/midi-polyphonic-expression-mpe
I'd say it's definitely doable in Pd, but ATM you would probably have to roll your own patch to get there. Sequentially assigning notes to channels shouldn't be too hard but some of the other facets of the new standard get a little tricky-er.




