LinuxMusicians

2 questions/wishes regarding jackd MIDI https://www.midi.org/:

1.)
If I understand correctly jackd does not send MIDI clock to external devices.

tramp wrote:[...] However, well known is as well, that jack-midi never was done for interact with "hardware synthesizers". For hardware midi handling you indeed better use raw alsa.
That changed, when interaction with software midi devices steps up in the game.
jack-midi is handled in the realtime-audio thread of jack. Developers needs to be aware that anything not real-time save shouldn't be done in the jack_process_callback, regardless if it is midi or audio. You may imagine that a couple of VSTi plugs ain't have a clue about this.

jack-midi does exactly what jeff proposed, no timestamp, plain messages handled as they comes in.
I must admit that I use midi only as a controlling interface, so jitter ain't matter for me, but, for my use case, jack-midi is the best, and painless choice for me and the users.
[...]

Could jackd send a stable MIDI clock to external devices?

2.)
Does jackd support MIDI 2.0 (SW/HW)?

khz wrote: ↑Sun Jun 13, 2021 4:09 pm Could jackd send a stable MIDI clock to external devices?

Jack itself didn't send any MIDI message whatsoever. Jack is a server. It provide a interface were midi messages could be send from on port to another. What ever you send have to be in a 3 byte range. That cover all possible messages in the MIDI standard 1.0 including MIDI clock. So yes, jack could send a stable MIDI clock, but, only as a connector, not as a sender.

True, the host/DAW reliably sends/receives the MIDI clock/messages, not jackd.
Are the MIDI messages transmitted by jackd with the same timing accuracy (RT) as audio?

Will ALSA/jackd support MIDI 2.0 in the future?

# I am not a developer and know very little technically, hence these questions.

However, well known is as well, that jack-midi never was done for interact with "hardware synthesizers". For hardware midi handling you indeed better use raw alsa.

This is a very confusing thing to say, lol
its true, but you get the same latency from jack and alsa.
https://jackaudio.org/faq/no_extra_latency.html

which means that in theory you could not get 100% of the processing power that you might get it if your application(s) used ALSA or CoreAudio directly. However, given that the difference is less than 1%, and that your system will be unstable before you get close to 80% of the theoretical processing power, the effect is completely disregardable.

You can ignore that part lol... in theory you can never get 100% of the cpu to just do all dsp instructions. I have no idea what that is about? tell me
processing power = performance ? lol

khz wrote: ↑Mon Jun 14, 2021 5:44 am Are the MIDI messages transmitted by jackd with the same timing accuracy (RT) as audio?

Yes. Jack sync MIDI messages with audio sample position. So audio and MIDI is perfectly synced in jack.

marbangens wrote: ↑Wed Jun 16, 2021 11:28 am This is a very confusing thing to say, lol

It's not about latency but about SysEx messages, were jack fail. If you need SysEx messages for your hardware you better use plain alsa for your hardware and bridge it to jack when needed.

tramp wrote: ↑Sat Jun 19, 2021 5:35 am Yes. Jack sync MIDI messages with audio sample position. So audio and MIDI is perfectly synced in jack.

Very good and I, a user, had thought so too. A developer like you, for example, has more in-depth knowledge and because of that can answer confidently and universally provable. Thanks!

tramp wrote:Jack sync MIDI messages with audio sample position. So audio and MIDI is perfectly synced in jack.

A bit more clarification here. This is true for Instrument VSTs (ie, a plugin that is a self-contained synth/sampler such as Yoshimi, or FluidSynth, or sfizz). But JACK doesn't have the means to sync external MIDI gear to sample position. ALSA doesn't either.

j_e_f_f_g wrote: ↑Sat Jun 19, 2021 7:24 am

tramp wrote:Jack sync MIDI messages with audio sample position. So audio and MIDI is perfectly synced in jack.

A bit more clarification here. This is true for Instrument VSTs (ie, a plugin that is a self-contained synth/sampler such as Yoshimi, or FluidSynth, or sfizz). But JACK doesn't have the means to sync external MIDI gear to sample position. ALSA doesn't either.

Daw's and jack use frames for time on a software level, I know jack uses hpet also. libasound (raw, not seq) seems to write and read midi directly without timestamps(with help of a hardware timer?). If you selected seq alsa you should according to https://www.alsa-project.org/alsa-doc/a ... fe725abb3d be able to send messages like MIDI clock or sysex and most of that good stuff from MIDI 2.0, but looking at jack2 source code I don't see that it's all implemented. If you look at https://github.com/jackaudio/jack2/blob ... ueue.h#L44 you see that raw alsa have a simple implementation and it should cover all of MIDI 2.0 from software to device. So if you have this problem selecting MIDI raw before you start jackd(jack2) should work. I haven't tested all of MIDI 2.0..

Jack need some improvements here(the midi sysex problem is reported), you could make jack not handle alsa midi if its a problem for you and you're program's can handle this anyway. But at the same time if you selected raw midi as a setting of jack it shouldn't be a problem for jack. It shouldn't matter if you use seq or raw, but seems like it dose. I think seq should be the correct setting for something like midi clock or sysex.

Love this wording here lol https://github.com/jackaudio/jack2/blo ... t.cpp#L106
The time that was before is now, space time is my favorite concept, time in space, what time anyway?