This is intended to be a general overview explaining the logic in how the oMIDItone handles selecting which MIDI notes to play.

The oMIDItone will make an array of all currently-on notes. This will be updated by MIDI Note-On and Note-Off messages.
Any pitch-shifting will apply to all notes without exception.

There are several scenarios that can occur here. Unchanging parameters:
    -There are 127 MIDI notes that can be played, any of which could be on.
    -There are up to 6 oMIDItones available at any given time, sometimes less.
    -You can use oMIDItone.can_play_note() to see if a specific note can be played by any specific head.
    -This results in a set of oMIDItones capable of playing a specific note, from 0-6 possible choices.

So we've got a set of notes, between 0-127, we should be playing, and we've got between 0-6 oMIDItones that can play any given note.

We need to decide which notes to play somehow, and which head to play any given note on.

Scenarios that can arise:
    1. -Notes exist that cannot be played by any heads.
    2. -Less notes than heads, all notes can be played on available heads.
    3. -Less notes than heads, some notes cannot be played on available heads. We will need to select which notes get played on which heads.
    4. -More notes than heads, all within the range of available heads. We will need to select which notes get played on which heads.

We should add a state variable that causes the logic to update only when a note value has changed to save processing time, as this seems like it could get a little complicated.

Solutions:
    1. -Trivially, we can map the max and min notes across all heads and ignore any notes outside this range to save time in for loops constantly checking heads to see what they can play. This should be done during the setup, after all the initializations are complete.
    2. -We check to see that there are only n notes on and >n heads capable of playing all the notes. We need to confirm there is no overlap or multiple notes that can be played on a specific head only and then we can assign heads without worry.
    3. and 4. -This is where things get more complicted. I see there are two paradigms we could follow for these cases to decide how to handle notes:
        A. -The first note that was pressed gets priority over newer notes if a decision has to be made to drop a note.
        B. -The most recently pressed note gets priority over older notes if a decision has to be made to drop a note.
            -B seems to make more sense, as Sodar pointed out that long chord sustains would override the melody bits.

Either way, it sounds like I will need to record the time of the note_on messages somehow so that I can iterate through the notes in the order they were sent to decide which way to operate. Current code only has an array that notes which notes are on or off, it might make sense to do this as an array that holds only the currently-on notes per MIDI, and keeps them in the order they were received. You can also remove notes from the array and shift the remaining notes when receiving note_off commands, adding them to the end of the array. This saves us from having to track the exact time the MIDI messages were received, and keeps things in chronological order.

Also, the chronological array has the advantage that if a note ends and a head that was in use becomes available, a different note can resume even if it was overridden previously.