a2jmidid configuration.
circuitikzuser opened this issue · comments
-
a2jmidid when running disallows any other application to directly use a midi pad controller.
-
This creates an untenable either-or situation as applications that need direct access to midi pad controllers are cut off when a2j runs. When a2j doesnt run, on the other hand, then programs such as Mixbus loses it's midi pad controller as Mixbus only receives control midi through a2j.
-
Further I was unable to find configuration files for a2j, where I can tell it to ignore a specific pad controller. This would solve my either or situation.
Question:
- If such a configuration (as in (3) above) currently exists, please point me to it.
- If it doesn't exist are you willing to implement it ?
It is clearly a problem that a2j by default cut off all other applications from their midi controllers and it is good practice fir a2j to have a config file whereby it can leave specified controllers alone or ignore them altogether.
As an explicit example. I lose my control surface working with Bitwig if I start a2j, because a2j seemingly just willy-nilly confiscate all the available midi devices even though most of the devices will not be used in jack.
It would be nice if a2j can exclude specified midi devices so other applications can continue to use their control surfaces while a2j runs.
I hope you see my problem/point.
sorry for the late replay! I somehow forgot to answer here!
I guess a2jmidid was not designed to fulfill this purpose.
I'm torn whether it would be worth the effort to provide this, as in the long run pipewire will unify all this (AFAIK) and jack2 is supposed to implement the a2jmidid functionality eventually (not sure to what extent).
The relevant upstream ticket is: jackaudio/jack2#360
For jack1 the a2jmidid code is already implemented as an internal client. I'm not entirely sure how it would help your situation though.
It creates big problems for non-jack aware and legacy midi software. As soon as a2j is activated, I lose all my direct communication to midi devices that legacy and non-jack aware software (like bitwig e.g. among probably 100's, even 1000's of applications) has with external midi hardware.
The other side of the catch 22 is the fact that Programs which are Jack aware such as Mixbus, will only communicate midi through jack if it uses jack.
The result is a situation that severely discriminates against non jack-aware software as soon as a2j runs.
It is a situation that you either use a2j and loose all legacy and non-aware functionality, just for one piece of software that requires jack midi therefore a2j.
The SOLUTION is clearly to make a2j do its job right, and only make those midi ports available to jack which the user decides in e.g. a textfile should be used through jack and leave the remainder alone.
This situation creates a completely broken either-or situation due to the a2j-take-all-midi approach which is currently implemented.
Think about it. LOTS of people depend on legacy midi software and there is no way in hell that legacy software canl be made jack aware. a2j therefore needs to do the right thing and be backward compatible, and not either-my(a2j)-way-or-the-highway with midi devices as is currently the case.
As a amidi user. This is probably the biggest Linux no-show at the moment in audio workstations on Linux.
have to disagree with you here.
the fact that jack applications want to talk with alsa midi is not something that is quite right.
when using jack for audio, applications should also use jack for midi.
the fault lies within jack to be overcomplex on the type of alsa-midi bridge to use.
or it could be said that this is a kernel issue, that opening alsa midi devices in "seq" mode should not block them from being used by other applications...
but in any case, a2j is not exactly in the wrong here.
a2j does its job by bridging everything. and not that it is not alone, pipewire does exactly the same for its jack-midi support.
falkTX
I communicated with the pipewire developers regarding this issue a few days ago.
What they told me is directly opposite to what you claim above about pipewire..
Here quoted straight from the Lion's mouth.
" PipeWire does not confiscate any raw device, it probes it and keeps it suspended/unused."
So a2j is what causes the trouble as Pipewire will do the above running e.g. inbetween alsa and jack as one of it's functionalities. It was made clear to me that pipewire will only make a midi connection if e.g. it gets a request from e.g. jack and only make the connection for the requested device and unlike a2j-bridge, wont just confiscate every raw midi device if it wants to make a single jack midi connection as is currently the case with a2j.
In my opinion interpreting their response, it therefore /makes a2jmidi obsolete - as it should as a2jmidi do not act responsibly making midi devices available when the bridge is running.
I was also explicitly told that pipewire will and already does replace the jack server completely and does all the connections and communication with Alsa for Jack enabled midi software. It clearly then leave all midi devices not
requested alone for other non-jack enabled midi and legacy midi to use the remaining midi devices .
So the logical conclusion is that the midi-grabbing a2j-bridge is therefore obsolete and completely discarded in favor of a per device allocation midi bridge in pipewire.
Pipewire when implemented will therefore free up the 1000s of legacy and non-jack aware software and non-jack-aware software to coexist with Jack midi applications, which are all currently held at hostage once you start the a2jmidi-bridge.
Currently with a2j this is not possible at all.
ok I can understand that.
I was forgetting about a crucial point about how pipewire handles this - even though it shows all available devices and ports, they are not actually activated until there is something connected to it.
While this is nice, I am not sure how it can handle with devices that are busy/taken for other applications.
But in the end, it kinda goes against the modularity of JACK. Because applications talking alsa-midi directly can take the device for themselves, thus preventing the rest of the JACK graph from accessing it.
There will be the case of a setup where many applications want access to the same MIDI input/output, and this is what a2jmidid provides.
I see some different goals here with a2jmidid and pipewire.
I would not say there is something inherently wrong with a2j, it just works different.
And now we are at a point where we are mostly maintaining it.
So there is not going to be a port configuration for a2j. For your own usecase, it seems that pipewire already works, and for many of us, we like a2j the way it is. And all is good, right?
Slowly we will move into pipewire, so I do not see a point of adding such functionality to a2j at this point.
Thank you for your kind response.
I understand.
As long as I have an answer about development of a2j and what you are willing to do, (both which you clearly explained) I can make the necessary changes.
As you say it works great for others, but for me and others wanting to use both jack midi and legacy non-jack midi a2j is a moot point.
Your response makes it clear that I have to move to pipewire for my needs.
I was reluctant to do it as my system works perfect, except for the midi issue and dont want to make big changes, that is why I tried to see if a2j cannot maybe accommodate my needs.
I appreciate your responses and this solves this issue
Thanks.
I was reluctant to do it as my system works perfect, except for the midi issue and dont want to make big changes, that is why I tried to see if a2j cannot maybe accommodate my needs.
you can use the jack2 "-X -raw" midi driver option, which allows you to use the midi devices with jack and alsa-midi at the same time. the bad thing here is that timing resolution of the "raw" mode is known to not be so great.
might be worth a try, specially if you run jack at low buffer sizes so the jitter/timing issues will not be so pronounced.
Thank you for the suggestion regarding jack2.
Unfortunately it renders most legacy software unusable due to data drops.
I guess that problem is one of the reasons pipewire was developed.
It seems pipewire is my only solution.