Jack can emulate an alsa sink, which enable a workaround, see: #13745

Switching to PipeWire makes Jack obsolete. However there is no MIDI in MS4 on Linux yet AFAICT. (Also MIDI in general is only partially implemented so far anyway, even in Windows...)

There is NO valid workaround for jack. I wish everybody stopped saying this.
Pipewire does not make Jack obsolete
It is because of comments like this that jack will never come back. Nobody can see the use of it.

This is really important for many of us, so we can output midi to our DAW directly. This was my main use of MuseScore.

It's important to me that I can select the MIDI input device.

Currently MU4 only shows the raw instrument from the USB-MIDI adapter as input device, but I need to filter the output to remove some faulty data sent by the keyboard.

Connecting the filtered MIDI signal to other apps (or to older Musescore) works fine, but MU4 doesn't show up in the patch bay. Also means I can't connect any virtual keyboards, or export Musescores MIDI output to other programs
Note: I'm mostly using ALSA MIDI on pipewire, patching the connections in QJackCtl, with JACK MIDI cross-compatibility. Either MIDI support would fix my issue.

I want to connect MS to a virtual keyboard in order to get a different/better playback (possible with MS3), but MS4 doesn't show up in qjackctl UI.

Even with JACK, or with a physical MIDI keyboard, you will find MU4 not particularly well suited for live MIDI playback. Too much latency, too many limitations. Better to use a program specifically optimized for real-time performance.

That said, implementing JACK would still be useful for other reasons. But also, note this particular issue is about JACK audio. JACK MIDI is perhaps a separate question.

I only can underline/emphasize the importance of JACK support. MuseScore IMHO is the best tool in its category in the Linux world, and also, support for Linux as a free and open source platform can and should not be underestimated - neither for education nor for production. In both areas a seamless, out-of-the-box JACK audio as well as JACK MIDI support is essential for a smooth adoption.
I am very glad to see this issue raised to P1 as a 4.x SHORTLIST item.
Thank you very much - and keep up the good work and Linux support!

Adding the "Community" label. This does not mean that we are lazy and are not planning to fix it ourselves; this means that we invite the community to give this a try, if anyone gets the chance for that sooner than we do.

If anyone would like to work on this, please reach out to us to discuss the implementation.

Doing Jack, more or less gives portaudio for free. More design info on ASIO and Portaudio:
#15354

Trying to shoehorn in jack (it doesn't work for now): https://github.com/lyrra/MuseScore4/tree/jack

In progress, by PR #19246 (awaiting first round of review).

I created this video for a discussion on the .org forum. Here it is for the relevant discussion regarding Jack (AUDIO) development vs. Jack (MIDI/Transport). I recognize that these 2 elements are structurally related, but I wanted to point out that they really need NOT be treated as independent in development for M4. In general, Jack (AUDIO) is not necessary at this point for audio routing to Jack applications in Linux due to Pipewire emulation. It seems to me that any development on Jack in M4 should focus on MIDI/Transport which may include audio routing, but not as the focus of development (as it is already addressed in Linux via Pipewire).

Video:
https://youtu.be/3LpXu1-wvlA?si=-EyvbkEzGac1DrAl

In summary, one can already route M4 audio to any Jack application right now. M4 doesn't need Jack to do this. It seems to me that any discussion about Jack that doesn't include MIDI/Transport is a solution looking for a problem.

I also want to reiterate that Pipewire does not make Jack obsolete, as suggested in a comment earlier. Pipewire does the opposite... it makes Jack relevant and useful with non-jack audio packages. Programs (Ardour, Qtractor, Blender, and many more) are absolutely leaning in on Jack feature support because Pipewire makes it smooth and seamless. To say that Jack MIDI/Transport is not useful, dying, or a poor substitute for some other real option requires evidence to the claim.

... Here it is for the relevant discussion regarding Jack (AUDIO) development vs. Jack (MIDI/Transport). ... In general, Jack (AUDIO) is not necessary at this point for audio routing to Jack applications in Linux due to Pipewire emulation.

Agreed, alsa can also route audio from client to jack directly.
But emulating alsa does not enable multi-audio channels, which would require a direct connection between Mu4 and jack.

It seems to me that any development on Jack in M4 should focus on MIDI/Transport
In summary, one can already route M4 audio to any Jack application right now. M4 doesn't need Jack to do this. It seems to me that any discussion about Jack that doesn't include MIDI/Transport is a solution looking for a problem.

How useful would it be to use a2jmidid as a workaround for midi-connecting MuseScore to Jack?

Agreed, alsa can also route audio from client to jack directly. But emulating alsa does not enable multi-audio channels, which would require a direct connection between Mu4 and jack.

It seems to me that this is resolved by M4 providing independent channel and bus outputs Alsa, Jack or otherwise. Pipewire could work with either, but I think this is an issue regarding what M4 provides with respect to channel sockets (unless there are some limitations to Alsa that would prevent this).

How useful would it be to use a2jmidid as a workaround for midi-connecting MuseScore to Jack?

I think that any solution that supplies live midi timecode from M4 should be workable for transport sync. I don't have experience with a2jmidid. What I know is that Pipewire is increasing in implementation without any serious challenge. So perhaps providing any type of MTC output (Jack or Alsa) would likely have a use... I think Xjadeo utilizes both.

I suspect that the bigger issues are with latency in the new play engine / Muse Sounds as it relates to real time external sync... but that's a guess.

Likewise, any sort of midi channel output socket (Alsa, Jack or raw) would probably find sufficient use in the world of Pipewire. I'm sure that I am ignorantly oversimplifying, but I think that folks just want access to data stream output sockets in whatever current forms that are there in M4, with respect to audio midi and midi time.