MIDI latency work about adljack HOT 7 OPEN

I've made workarounds, now it's possible for winMM to work.
In the latency range which used by the standalone Windows software, adljack seems to work now better. But at higher latencies in 100ths ms, it becomes more and more crap as value goes up.

I've raised MIDI buffer size as necessary, because now it must have capacity for accumulation of MIDI events for a longer duration.
For now, MIDI input does not act in RT way, waiting to have available buffer space if it's full. No problem for ALSA MIDI, but in case of Jack, it can create xrun.

No work was pushed to the master branch, while ALSA remains broken and needs identifying the precise problem.

from adljack.

I saw you have took some fixes into RtMidi library. Does this helps you to solve ALSA MIDI trouble with time stamps?

from adljack.

At least, the timestamp don't emit crazy values at this point, but still some trouble remain.
I've not merged yet, into this adljack branch, the RtMidi patches I got accepted upstream.

The last time tried, ALSA had still trouble despite patching, the midi event delays were not all well spaced at arrival. I think, I have demonstrated that RtMidi has a really weak point on timestamping and needs more fixing.

However, the winMM situation is well improved, in the moderate buffer size values, such as upper bounds savihost has. Still, in the very high range (think 0.5s and up), the MIDI gets increasingly desynced, meaning still that something is wrong with damn timestamping.

At one point, I should compare RtMidi vs Juce code in ADLplug, because that other manages to gets the timing all perfect without any troubles.

from adljack.

@Wohlstand so, right now I merged in the timestamps code.
It's not perfect but I expect it to help the latency problem. Please give a try on your side.

from adljack.