How do I retrigger repeated notes in poly~ ?


    Mar 10 2021 | 9:17 pm
    I want to send notes to a synth (with a longish release), using poly~ and have the voices play polyphonically. This is straightforward if the notes aren't repeated before they fade out, but I can't work out how to retrigger repeated notes, so that playing, say C3 repeatedly doesn't just use up all the voices to play C3 in a huge chorusing layer and cut off the other notes. I just want it to behave like a piano or guitar would. Anyone?

    • Mar 12 2021 | 11:57 pm
      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!
    • Mar 13 2021 | 10:00 am
      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 ...
    • Mar 13 2021 | 5:34 pm
      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)
    • Mar 14 2021 | 11:26 am
      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.
    • Mar 14 2021 | 12:11 pm
      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.
    • Mar 14 2021 | 12:49 pm
      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
    • Mar 14 2021 | 2:00 pm
      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!
    • Mar 14 2021 | 2:25 pm
      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