So here is a midi (input) driver for jack. The audio/midi driver share the same jack client, I documented the assumptions I have to make for the communication of the two in the code. While the audio driver typically only has one option (the default audio device), for midi there can be more than one choice. For example here is the relevant part of --bse-driver-list on my system if I configure jackd to do the midi handling - we get one possible device in this case:
Available MIDI drivers:
jack=system:midi_capture_1: (Input, 01000000)
JACK Midi "system:midi_capture_1" [Physical: in-hw-2-0-0-UA-25EX-MIDI-1]
Hardware Midi Input
Routing via the JACK Audio Connection Kit
Note: JACK adds latency compared to direct hardware access
And the same system using alsa midi bridge setting in cadence (uses a2jmidid):
Available MIDI drivers:
jack=a2j:Midi Through [14] (capture): Midi Through Port-0: (Input, 01000000)
JACK Midi "a2j:Midi Through [14] (capture): Midi Through Port-0"
Hardware Midi Input
Routing via the JACK Audio Connection Kit
Note: JACK adds latency compared to direct hardware access
jack=a2j:UA-25EX [24] (capture): UA-25EX MIDI 1: (Input, 01000001)
JACK Midi "a2j:UA-25EX [24] (capture): UA-25EX MIDI 1"
Hardware Midi Input
Routing via the JACK Audio Connection Kit
Note: JACK adds latency compared to direct hardware access
So here we get more than one device entry, and if there were more midi devices we would get even more. In this case we have relatively long device names, but we need both: client name and port name to distinguish between devices.
I also added a comment about auto connect which should really be configurable one day; still even without that the midi driver should be usable.
https://github.com/tim-janik/beast/pull/129
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.