MIDI delay when placing tokens. Timing issue.

Thanks for the great reply!

I think you should consider reversing thread priorities -- in that timing should be the highest priority and should be the foundation for everything. The UI is fantastic and the hexagonal layers are great to just watch, but ultimately you are building a sequencer.

Most DAWs and commercial sequencers drop UI elements and animations over compromising timing.

totally agree with Octatone,
can also confirm for myself that its when CPU cycle saturate that the offsync occurs.
Its a close to be forgotten paradigm that audio/midi needs to have thread priority over UI, now that machines almost touch the sky with their gazillionHertz speed. Any Audio/Midi developper can tell you, ten years ago everybody knew that fact, because you had no choice, but now if you develop on a fast enough machine you usually don't notice it during development because you do not usually test the software has hard as a musician will do, because usually musicians will always push their CPU till the last drop of processing power because computer are still not fast enough for their needs. Software synth and Effect ARE processor hungry, you can certainly top ANY machine's processing power by loading a few instances of a convolution reverb, and this is what musician WILL do.
So, understand me, I really do not mean to bash anything Elysium do here, Elysium is a very refresing musical paradigm and really ROCKS!
I only mean to put a bit of historic perspective on the problem.

So,
In my opinion, the safest way to get timing right, would be like octane said, to put UI behind midi in terms of priority, but also, the problem here is that notes play late, then everything behind gets delayed and detailed rythmic figures go out the window... so if you had a SAFETY kinda jump FUSE mechanism, where events are played ONLY IF they can play in time, OR skip and play on next iteration, the end result would then have missing notes, but at least all played notes would have the right timing. Many say that music is not what you play, but when you play it, so based on this, there is no use to play 100 out of tempo notes, while playing half of them on time would yield better musical results.

Please take my comments lightly ;)
But please also take into account I have been doing professionnal sound design, as my day to day job for the past 12 years, so I have seen many hardware and software and most of the evolution of computer music happen, and as a result, I have a very opiniated professionnal perspective on the subject.

Thanks For Your time,
I really appreciate the work you are doing,
and understand the kind of work all those issue involves as I also happen to do some programming in my spare time.

regards,

L-P

Thanks, I will follow how it evolves in next releases and will keep the feedback coming.

I have no idea about the inner brains of your program, but I want to offer some ideas instead of only leveling criticism.

What if you had I high level thread as your timing clock and a separate high level thread to deal with the collection and sending out of MIDI messages. Right now, it sounds like you are saying the layers themselves send out the MIDI messages. What if on each beat a MIDI thread is notified to release all current MIDI messages first before notifying the layer threads to calculate all the business of playhead movement, tokens, and notes for the next beat -- that the layer threads only deal with calculating the next notes and sending them to the MIDI thread's queue.

If the layer threads send notes to the MIDI queue late, you could have a timing option to either flush late messages or to send them out on the next beat.

Procedural pseudo code:

Main(
While running
If (beatThread.isBeat){
notify midiThread.releaseQueue()
notify all Layers.calculateNext()
notify UI.update()
}
)

In my mind, at least, that seems like a quick solution to getting rid of MIDI delay from waiting on the layers to send out MIDI messages.