-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MuseScore not supporting JACK audio anymore (Linux) #16787
Comments
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. |
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 |
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. |
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: 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: 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. |
Agreed, alsa can also route audio from client to jack directly.
How useful would it be to use a2jmidid as a workaround for midi-connecting MuseScore to 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).
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. |
Issue type
General playback bug
Bug description
MuseScore used to support the best audio engine out there, which is JACK Audio Connection Toolkit. On version 4.0.x it is not there anymore. It is highly necessary to route MuseScore audio or MIDI playback to other applications. In the case of MIDI, it can be also used to input MIDI in MuseScore.
Steps to reproduce
Screenshots/Screen recordings
MuseScore Version
4.0.2
Regression
Yes, this used to work in Musescore 3.x and now is broken
Operating system
Ubuntu 22.04
Additional context
No response
The text was updated successfully, but these errors were encountered: