Reversal of round robin assigner to first available voice

[image-et-son]

This change is from GliGli (last residual thing he wanted to change in 2015). For assign a voice to a played note round robin always selects the voice that has been idle longest from those available. This cycles through all voices. The idea of changing it back to first available voice (by voice index) is that for playing a note repeatedly (and in case this note is finished, because otherwise it is simply retriggered on the same voice) the same voice is used. Voice may have different tuning and obviously this becomes more significant with vintage spread on (in which case the cycling through the voice can also be a feature, though).

The commit in which the first available logic was changed to round robin is here: https://github.com/gligli/p600fw/commit/a7ffe293df275cbe0f47b4b004acc9a685a2dda9#

[matrix12x]

I like round robin, so repeated notes don't sound like a machine gun. It makes baselines sound more "organic."

I 100% prefer not to have the same voice repeated on a repeated keypress of the same note. I prefer to have them cycle.

[image-et-son]

Hi, I'm in contact with GliGli and he appreciates the efforts here. It would be great if he'd approve of the new version. Since this is the only pending change proposal from him, I feel obliged. But I see the point (as in my description), so in the end I might just make it a patch (!) parameter. I might even introduce a third option "multi" which assigns new played notes to new voices even when the same note is still ringing out on a voice.

[el-folie]

Personally I like the original SCI P600/P5 reassigning mode the most as it gives a note on the keyboard sound consistency due to the linking to a certain voice until stolen. This is very important for poly-mod and detuned sounds.

But of course there are use cases where pure "round robbing" makes sense to make the sound more lively, detuned and non-static. So, having different voice allocation modes as a user parameter would be nice.

[image-et-son]

OK, we then just need to settle for a default :-)

[el-folie]

Maybe the default should be the original Z80 mode? So like P5 I guess.

I can do tests on Z80 if needed...

[el-folie]

I´m definitely getting weird behaviour like notes hanging in "multi". Also new CV pitch glitches in all modes it seems, need to monitor further...

The new glitches are like this: when pressing a new note, it is first being pitched to a former note pitch that is not any longer held or sounding. So maybe a matter of pitch CV update delay on key press in some unknown cases?

[image-et-son]

"multi": maybe I was a bit hasty here because it seemed easy and I am overlooking places in the code which assume that you can only have each note only on one voice. I will remove the "multi" option because finding and fixing bugs produced by it would just delay work on other, more important topics.

The glitches sound worrying. Maybe it is related to my fix of the Glide bug? Did you have those glitches in 13 already?

[el-folie]

I´ll go back to alphas 13 and 10, test playing the same patterns there, mostly octaves in the lower registers plus arpeggios ontop higher up the keyboard. Will report back.

[el-folie]

1. No such things happening on alpha13, so not needed to test alpha10.
2. Testing 13.1 again

[el-folie]

After extensive testing 13.1 again, I couldn´t replicate the glitch for First and Cycle, but definitely for Multi. Multi is buggy with multiple chords/arpeggio/long release times.

(Maybe it was just my P600 hardware again, there are still some rare pitch cv glitches sometimes that I can´t put my finger on. It´s just that on Z80 they are def not there, never happening. Probably some "wait state/delay/chip/response time thing" that gets better after warming up and is not there on Z80, maybe as it doesn´t refresh the hardware as fast as the teensy.)

[image-et-son]

No, I think it was naive to think it could be made to work that easily. I remove it.

[el-folie]

Hm, maybe there´s also some Teensy memory thing coming into play? Maybe after changing from Multi back to Cycle and First there was still some note/keyboard assigner residue in memory that made glitches appear also in First/Cycle, but only once? But yeah, Multi was/is buggy due to hanging notes.

[matrix12x]

Alpha 13.2 First and cycle seem to work fine on my machine. I switched back and forth and had no problems. What I did notice was that if I use some vintage, a very short decay, no sustain, no release. when I do fast runs or turn on arp, I definitely notice a difference in how the notes sound.

[image-et-son]

I suppose that is exactly why the two options are there. There might be inherent hardware differences in the voices, but a least to my ears the difference manifests itself with spread and you need to short notes so that the notes don't ring out long in which case I guess there effectively not much difference between first and cycle as the assigner priority (low, last, high) dominates.

Speaking of which: I noticed with the assigner change that in the "stealing" in "last" setting if you hold down 7 keys and release one, the oldest is first stolen and then reassigned but the timestamp of reassignment is set to zero so if you press a seventh key again a different note (the formerly second oldest) is stolen an so on. I'll check how that worked in the past.

[image-et-son]

I looked into the "steal" logic now: the original GliGli assigner reassigns note 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 the next stolen will be a different one in priority last.

I means it's really detailed, but do you have an opinion on this?

[el-folie]

I have to admit that I needed to read a few times through the voice allocation analysis above to slowly understand how it works. Then I checked back on Repro5 to see how it behaves when stealing voices (as it is supposed to perfectly recreate Prophet 5 behaviour, U-he are known for precise emulation).

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.