Proper consideration of timestamp while reassigning stolen notes in priority "last" mode

[image-et-son]

Currently: the assigner reassigns notes which have been stolen, once a voice becomes available (again) but it is simple in two ways. First, it looks for lowest unassigned note in priorities low and last and it looks for the highest unassigned note in priority high. No time is considered because - second - the timestamp is stored with the voice assignment and since the unassigned notes have no voices the timestamp is lost. So reassigned notes get a new timestamp and therefore next stolen note will be a different one in priority last because that logic uses the timestamp to look for the oldest one.

Proposal: first, when reassigning a stolen note the assignment should receive the original timestamp of the stolen note, or at least it should get a timestamp that is older than the oldest timestamp of all held notes. Second, the reassignment should - in priority "last" mode first look for the oldest unassigned note an reassign that (currently the lowest is chosen, see above).

Prophet 5:

Note priority in poly mode is last (no hi or low on a standard P5 in poly mode):
If I set the voice count to 4 (for easier testing), press and hold 4 notes and then a fifth note, the fifth note is being assigned to the oldest voice, so that the first note still held is being stolen. When I release the fifth note and press it again it is being reassigned to the same voice again. When I play a different fifth note it is being reassigned to the same voice again, no 2nd oldest voice is being stolen. And, when the first 4 notes are being held and 4 new notes are pressed, the voice allocation completely steals all the voices from the first 4 notes, so that when I release the new 4 notes there´s no voice playing anymore, despite the fact that the first 4 notes are still being held. (Seems weird to not reassign to the still held 4 first keys as it´s last note priority, but it´s a vintage synth so maybe that´s just how it was.)

This is from the P5 manual:

I also just checked back the P600 Z80 behaviour, so that we know how the P600 originally behaved. And it´s the same as on Repro5, when 6 new notes are being held and released, the first 6 notes still being held don´t sound, they don´t get reassigned to voices. Odd... but that´s how it was. In that regard I like the new GliGli voice allocation better, as it always assignes voices to notes still being held.

Originally posted by @el-folie in #100 (comment)