I’ve read your responses several times. To summarize what I’ve learned: I was hoping to avoid using the audio thread, but now it seems that this would be a mistake, and that I will have to use the audio thread for timing. This should be done in the form of a timeline or playhead which synchronizes internal sequence events with audio blocks, and also timestamps incoming events.
If I make a rudimentary playhead like this now and then build my code around it, will I at least be heading in the right direction? Again, I am not looking for perfection at this stage–I am mostly trying to avoid the scenario where I have to re-write 6 months worth of code because of poor design choices.
@daniel, you have suggested that I stay away from multi-threading for as long as possible. This has always been my intention, but I don’t see how it will be possible if I’m going to be using the audio thread for timing. Surely I need some way of ensuring thread-safety. Or am I mistaken?
About the queue question, I did look at some of these Midi classes, but what I need to cue are strings, not Midi events. Perhaps I could store strings as meta-events on the MidiMessageSequence?