Hmmm, right now, once you use a SendLater function, the event is put in a queue so that it, well, gets sent >later, going right into the MIDI out queue. The assumption of course is that when you do a SendLater, you >always want it to get sent. What is your scenario where you would send a note out into the future and then >need to change it later?
Just change the routing goal, currently done via Midi channels.
But your comment is interesting — the notion would be that one could schedule an event into the future and >then capture it at the point when it’s about to go out and run script code.
The routing roles (to the instruments) can be calculated after receiving some notes in the played first chord
inside an as small as possible time window after sorting them related to Note Number.
It probably wouldn’t be too hard to implement such a feature but I think it requires some thought. For >example, do we now need to know whether a callback is handling a real-time note that was just played or >whether it’s handling a note that was scheduled from earlier? Do we need to have a completely new set of >constrained callbacks to respond to these or do we extend the existing callbacks with another argument to >indicate what kind of event we are receiving.
Inside the first chord-timewindow the roles can be assigned,
it must be calculated to which voice (role/Midich.) of a chord the incoming note should belong.
That can be done by the addition of the note to the right position in
the note number sorted Array and some Midi control … how this exactly happens, … later tbd
If/when I get it to work you can take a look, I can’t really say anything more now