This seems like something simple, but I can't work it out. I know I could solve this with a poly~ of 128 voices , using each voice as a mono synth, but its too much memory to load that many voices. I only need about 8 note polyphony, but I don't want to eat up the polyphony with repeated notes. It would be great if poly~ had a retrigger flag!

try using target messages together with output of thispoly~ to form sort of midi note number to voice number assignment. If a voice instance is still on, receiving it's current note number should be targeted to the same voice instance. But I can't tell you how to do that without seeing what exactly you send to poly~ and it's exact structure. Or if that works for your needs, use 12 poly voices and map chromatic scale to 12 voices, would kill simultaneous octaves though ...

Here's an example that shows one way of retriggering voices in a poly~ and comparing it to using midi note, you can see the way midi note just cycles through all the voices, as oppose to re-using voices if a pitch is already sounding. There is probably a much better way of doing this though, and this breaks if you use more than 10 pitches (i.e. voice stealing doesn't work)

you need to set @repeatmode 1 atribute for makenote. At least in this poly~ configuration. I made some modifications and reduced it to retrigger part. I hope that it works so for you. I've done it using Max 6, gui might look a bit different in Max 8.

Thanks, that's neater, but I'm not clear how it works better than my patch? Your patch still doesn't work properly with more than 10 notes - if you use say 24 notes, and a 3s release, the "notes" coll gets filled with errors quickly, same as my patch, and the stealing sounds wrong. With ten notes or less it would be a lot easier to just allocate a voice for each note with target.

The patch I posted has beside reduction of used elements only 1 important difference : repeat mode set to makenote, which forces it to retrigger allready sounding note, by first turning it off. But simply technically, I see voices activate and deactivate as they should. Only if metro time is greater than note duration ... Maybe one should take different approach for note-voice target linking. The way it is, allows coll to store several notes to same target number, which should not be the case P.S. voice stealing does not work if note or midinote messages are not used

300ms note length and 3 seconds release means 3300 ms voice active status per note. with 10 voices, one should genearate notes with at last 20 - 50 ms longer metro interval than 330 ms

The problem left I think is to implement voice stealing and still keep track of which notes are assigned to which voices. Repeat mode 1 maybe prevents an old note from cutting a new note assigned to the same voice off too soon, but I don't see why it would force the retriggering of the same voice? jit.cellblock is great btw!

repeat mode 1 turns sustaining note off prior to retriggering it . That makes a difference for adsr~ object, depending also on it's own settings.

You set adsr~ to legato, which I did not know when sugessted to use repeat mode. Open makenote help file / Repeatmodes and max console and then trigger same note 4 times in each variation Maybe repeatmode 2 would suit your poly application better ? And yes, some better logic for voice allocation should be done. If metro speed is set so that it is 50 ms longer than sum of adsr release and note length time divided by 10 then all runs just fine