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

@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.

so now the voicetest is an abstraction I write them like so? but then the tabread4 object read from a different table number other than the table which is i.e 1 in gridsamplerptest as well as the the other objects?

@Fauveboy In the example you poster earlier they had the $1 argument. That works.

so ive returned the it to voicePTest $1. i think for some reason the catch an throw objects are having trouble with the arguments they have perhaps....this screen shot is with the DSP on but the values arnt passing to each other here?....

is there a difference when using $0 or $1?...just realised that $0 is assigned a four digit value and $1 indicates sequencial arg.

Im getting warnings saying things are getting multply defined which suggestes the voiceptest's are deriving the same arg val?

@Fauveboy Yes there is a big difference. Everything that needs to be unique for the calculation of each voice needs a $0 (unique for each instance). If they get the $1 then every throw and catch in every voice will be having the same name.

inside gridSample is where the audio sample is loaded. there are objects which send that file size ect to the voice abstract that have arguments of $1 if they were $0 would they not be different from the voice abstract and therefore not receive the data ?