Keeping track of note-ons and note-offs for a polyphonic synth can be a pain. Luckily, the [poly] object can be used to take care of that for you. However, the nuts and bolts of how to use it may not be immediately obvious, particularly given its sparse help patch. Hopefully this tutorial will clarify its usefulness. It will probably be easier to follow along with this explanation if you open the attached patch. I'll try to be thorough, which hopefully won't actually make it more confusing!

To start, [poly] accepts a MIDI-style message of note number and velocity in its left and right inlets, respectively...

[notein]
| \
[poly 4]

...or as a list in it left inlet.

[60 100(
|
[poly 4]

The first argument is the maximum number of voices (or note-ons) that [poly] will keep track of. When [poly] receives a new note-on, it will assign it a voice number and output the voice number, note number, and velocity out its outlets. When [poly] gets a note-off, it will automatically match it with its corresponding note-on and pass it out with the same voice number.

By [pack]ing the outputs, you can use [route] to send the note number and velocity to the specified voice. For those of you not familiar, [route] will take a list, match the first element of the list to one of its arguments, and send the rest of the list through the outlet that goes with that argument. So, if you have [route 1 2 3], and you send it a list where the first element is 2, then it will pass the rest of the list to the second outlet because 2 is the second argument here. It's basically a way of assigning "tags" to messages and making sure they go where they are assigned. If there is no match, it sends the whole list out the last outlet (which we won't be using here).

[poly 4]
| \ \
[pack f f f] <-- create list of voice number, note, and velocity
|
[route 1 2 3 4] <-- send note and velocity to the outlet corresponding to voice number

At each outlet of [route] (except the last) there should be a voice subpatch or abstraction that can be triggered on and off using note-on and note-off messages, respectively. In most cases, you'll want each voice to be exact copies of each other. (See the attached for this. It's not very ASCII art friendly.)

The last thing I'll mention is the second argument to [poly]. This argument is to activate voice-stealing: 1 turns voice-stealing on, 0 or no argument turns it off. This determines how [poly] behaves when the maximum number of voices has been exceeded. With voice-stealing activated, once [poly] goes over its voice limit, it will first send a note-off for the oldest voice it has stored, thus freeing up a voice, then it will pass the new note-on. If it is off, new note-ons are simply ignored and don't get passed through.

And that's it. It's really just a few objects, and it's all you need to get polyphony going.

[notein]
| \
| \
[poly 4 1]
| \ \
[pack f f f]
|
[route 1 2 3 4]
| | | |
( voices )

http://www.pdpatchrepo.info/hurleur/poly_tutorial.mmb.pd

All of those extra notes are because of [bondo]. Every inlet in [bondo] is hot, so when one inlet receives a value, all outputs are dumped. So every time you press a key, it will spit out values three times. You really don't need [bondo] at all here.

Check out the attached tutorial sequel. It should explain how to do what you want.

http://www.pdpatchrepo.info/hurleur/poly_tutorial2.mmb.pd

You're a lifesaver. <3, <4, & <5.

Thanks for a great tutorial, solved my poly woes instantly!

Filippo

Thank you! Really helped me get started with polyphony. I'm wondering. Is there a way to put the osc~ outside the sub patch. I'd like to switch between different waveforms effecting all voices at the same time.

Thank you for this. It is a great help, and the patch makes it so easy to learn. I'm going to have my custom-tuned, polyphonic midi setup running in no time.

I Love pd.

Thanks for the tutorial! It did help me gain further insight with [poly].

Still, there are situations in which it remains difficult to work with polyphonic MIDI. Especially when the notes change (at random or by calculations). Fairly easy to get “hanging notes” if [poly]’s voices get mixed up.

Here’s a patch which gets stuck notes with polyphonic input:
poly-hanging.pd

Poly does the right thing when it can keep track of the voices, but it doesn’t send the correct note off message if the voice has changed. Tried storing the note number in a [float] and banging it at note off. In that case, it does stop the note when the key is pressed again in the right order. But it’s still far from the desired outcome.

Eventually, this is part of a project to have rotating notes under an incoming melodic line (the “Michael Brecker Effect”). Funnily enough, it was based on polyphonic support by the Oberheim Xpander.

Been documenting my previous attempts elsewhere in the forums.

Any help would be appreciated!

@Enkerli Hello there. I don't use midi........ but..... when is the right time for the "note off"? If you want the notes to revolve then I imagine you want them to "hang around" but for how long?
I didn't see the abstraction "note" in your upload, so it's hard to tell, but I would expect that you want the "note off" sent when the adsr has completed?
You could collect the incoming note numbers within the [note] abstraction and send a "note off" after a delay equivalent to the total of the adsr times. As [note] is already an abstraction it should be easy.
David.
Actually the total adsr time would need to be divided by the stack length..... and the faster the notes come in the faster the values will be pushed from the bottom of the stack anyway...... and so they will be cut off in their prime.... good? of bad??..... length of stack?
Just ideas!

The way ADSR is calculated in most midi devices is usually a combination of both the ADSR settings and the length between the note on and note off messages. The note off is typically received before the completion of the envelope and determines when the switch between the sustain and release phase will occur (often, the note on/off determines the minimum time and the sustain setting sets the maximum). Some synthesisers have the ability to switch between a GATE and ENVELOPE mode, and playing with this toggle whilst triggering a string of notes will make the way in which the function works more obvious.

Of course the whole note on/off-ADSR relationship varies with the way the device or algorithm is programmed -- for example, note velocity can also affect the attack phase -- but that's generally how it works.

Didn’t do a good job explaining my issue. And sorry about forgetting the abstraction. Didn’t think about that.

My issue isn’t really related to the envelope, AFAIK. Had the same problem sending MIDI out (where the external synth dealt with the envelope). The idea is to have notes play as long as the key is pressed on a MIDI keyboard (or air is flowing through my wind controller). On key up (or breath stopping), some controllers send a velocity of 0 that Pd uses as “note off”. My intention is to finish the note when that happens. Works really well with [poly] when the voices remain the same. With or without the envelope. But my little rotating offset throws off [poly] and that’s when notes start hanging.

@whale-av Your idea of collecting incoming notes is pretty good but how is that done? Should it be [tabwrite] and [tabread]?

@Enkerli As posted above, but I also forgot to post the patch......... poly_hang.pd a "sort of" tabwrite / tabread is created by the stack of [f] objects, and the "notes" are driven down the stack by incoming notes, and forced down the stack by the [metro] even when no new notes arrive..... the length of the stack depends upon how "busy" you want the polyphony to be.
Or yes, you could use tabwrite and tabread with a delay of the read.
David.

I think you'd be better off having the note offset occur in the voices themselves (i.e. after [poly]). That way you aren't screwing with the actual MIDI note value before it hits [poly], and therefore it will be able to keep track of the notes.

i attempted the poly design with sampled audio on my patch heregrid2.pd gridSampler.pd

I started copying and pasting code in the 1st pd voice sub patch you'll see inside the gridsampler sub patch but i believe the receive and send objects get confused if they're using the same array?

Is there away to avoid this for polyphony with samples?

@Fauveboy I think the pd voice subpatch needs to be its own abstraction in order to have the unique send and receives for each voice.

but then if I load the subpatch gridSampler 1 and all the $1 inside are 1 what does that mean for the pd voice and the numbers it gets ? is it possible for it still to read the array from gridSampler 1?

@Fauveboy said:

but then if I load the subpatch gridSampler 1 and all the $1 inside are 1 what does that mean for the pd voice and the numbers it gets?

if the "pd voice" instances are subpatches (like they are now), they argument for gridSampler is passed down to them as well. You can see this if you open one of the pd voice subpatches, they are called "voice (1)".

@Fauveboy said:
is it possible for it still to read the array from gridSampler 1?

If you turn the pd voice into an abstaction, it is still possible to read from the same table that is located in the gridSampler patch. The problem you have here, as far as my understanding goes, is not that the subpatches are addressing the same table, but that they are doing so with the same phases. To solve this I think you need abstractions for the voices, and the reading mechanism for each of them (aka the note each voice plays) needs to be unique, and you do that by using $0 inside the voice abstractions.

@Fauveboy Does it work like this?

gridSampler.zip

I agree though that it seems from all your posts that what you are trying to do is pretty complex so if you shared all the patches involved and a detailed, but above all clear explanation of what you are trying to achieve it would make it infinitely easier for us to help out.

So grid2 loads has an instance of gridSamplerPtest X (in this case 1).grid2.pd

Inside needs to load one sample.
gridSamplerptest.pd

Inside each voicePtest needds to read from the sample array loaded in the gridSamplerPtest. The intenion is four the voicePtest to let me playback the sample sample simultaniously at different pitches.voiceptest.pd

won't voicePtest $1 derive there numbers from the argument I give gridSamplerPtest X ? and therefore inside voicePtest all the objects derive the sample argument....so I just have four voicePtest with the same argument?

@Fauveboy Yes that's right. In the previous example though pd voice was a subpatch and they shared the same $1-phase objects and the likes. When you use polyphony some things need to be global (the sample readout table, the sample length) and others need to be unique to each voice abstraction (like the note transposition, envelopes ecc).

I think of it like this when it comes to arguments: whenever you write a $0 or $1 argument in an object, they address the arguments of the patch they are in, which means the unique $0 of the patch they are situated in, or the argument of that same parent patch in the case of $1. Like this you can pass down arguments in a russian doll fashion even when you have many layers of nested abstractions.