jack-midi support

[lyrra]

• I signed the CLA

Purpose

For linux users, the ability to at runtime switch between alsa and jack audio+midi driver.

Changes

• Make both jack and alsa(linuxdriver) more similar to osx-driver
• Make jack and alsa drivers "subdrivers" of linuxdriver (AudioDriverState).

class design changes

Before:

AudioModule
│
├── LinuxAudioDriver
│   │
│   Alsa
│   └──> device: "default"
│
├── OSXAudioDriver
│   ...
│
└── WasapiAudioDriver
    ...

MidiModule
│
├── LinuxAudioDriver
│   │
│   ├────> AlsaMidiOutPort
│   └────> AlsaMidiInPort
│   
:

After:

AudioModule
│
|         MidiModule
│             |
├── AudioMidiManager (was LinuxAudioDriver)
│        |      │
│        |      ├─── JackDriverState
│        |      │    │
│        |      │    (jack-code)
│        |      │    └──> jack client open
│        |      └──> AlsaDriverState
│        |                      │
│        |              (alsa-code)
│        |                      └──> device: "default"
│        │
│        + LinuxMidiOutPort
│        │
│        ├────> JackMidiOutPort
│        ├────> AlsaMidiOutPort
│        + LinuxMidiInPort
|          :
│
├── OSXAudioDriver
│   ...
│
└── WasapiAudioDriver
    ...

MidiModule
│
├── AudioMidiManager (was LinuxAudioDriver)
│   │
│   + LinuxMidiOutPort
│   │
│   ├────> JackMidiOutPort
│   ├────> AlsaMidiOutPort
│   + LinuxMidiInPort
:

Audio Tests

• start with jack, play and hear audio OK
• start with alsa, play and hear audio OK
• start with jack, switch to alsa, then play OK
• start with alsa, switch to jack, then play OK
• switch from jack to alsa during play OK
• switch from alsa to jack during play OK

Midi tests

• start fluidsynth in verbose mode, musescore and qjackctl (to midi-connect them), verify midi-events are logged by fluidsynth.

Optional cleanups / redesign

Remove LinuxAudioDriver and keep only AlsaAudioDriver and JackAudioDriver as two independent implementations. To switch between them, you need to add another class, something like IAudioDriverProvider. This is what you need to add to IoC (and remove the drivers from IoC). Access the driver through this class, like:

class IAudioDriverProvider ...
{
...

        std::shared_ptr<IAudioDriver> driver() const;
  
        void swithDriver(const std::string& name); 
        async::Chanel<std::string /*name*/> dirverChanged() const;
}


class SomeClass
    Inject<IAudioDriverProvider > audioDriverProvider;


...

     audioDriverProvider()->driver();

This greatly simplifies everything, each class becomes simple and does one thing.
Moreover, such a system is easily scalable; we can easily add other drivers, cross-platform or platform-specific.

Not in scope for this PR

• MIDI-channel-per-instrument

Known cleanups & fixes before merge

• send foreign commits upstream:
  Misc. needed for jack #22373
• cleanup: avoid global in app
• If possible do mutual dependency Injection between module Audio and Midi.
  Testing confirmed, can't inject modules.
  Injection is used, but not at modul level.
• de-pollute any interfaces that got sprinkled with data members
• ensure no public data members begins with m_ (those should be private)
• remove sample-rate dropdown OR make it work,
  No 'requires restart' added
• automatic connection to audio ports upon start
  Not in scope, brings in too much arbitrary heuristics code from Mu3.
• Possible to switch between jack/alsa driver (currently it crashes)
• Possible to switch bufferSize in jack without crash (possible in alsa)
• Possible to disable jack-transport via configuration checkbox

[lyrra]

Why has it been closed?

• The code quality is too low -- too much to refactor/cleanup
• Only halfway implemented (The concept of audiomanager is based around linux)
• merging would introduce alot of "tech debt", nobody would cleanup that, causing further hacks ontop
• By keeping this open I stand in the way of others wanting to take a bite at jack (already done that by samplerate selection)

[davidhealey]

@lyrra Ah I understand, that's a shame because you've put a lot of work in. Do you plan to continue in another PR or are you moving on to other things?

[cfirwin3]

@lyrra This is devastating. Who else is working on this capability? I don't know of any other serious or remotely successful attempts to acquire sync.

I actually use this... all the time... for real world work.

Devastating.

[cbjeukendrup]

Devastating.

Not so dramatic! Nothing is lost. There were two ways to get this feature in: either we'd merge this PR and perform refactoring afterwards, or we'd close it and use the research findings from this PR to build a streamlined implementation in a new PR that would be merged. So now, the second way it is, which is as least as convenient as the first way.

[cfirwin3]

Devastating.

Not so dramatic! Nothing is lost. There were two ways to get this feature in: either we'd merge this PR and perform refactoring afterwards, or we'd close it and use the research findings from this PR to build a streamlined implementation in a new PR that would be merged. So now, the second way it is, which is as least as convenient as the first way.

Someone has to want to implement a new PR first. Then they'd have to do it as well as it was done hear. I have little faith in either. For my situation, I was using this build for real work. I have 8 films on my plate now, and without the promise of a continuation elsewhere, I can't realistically take on much more. The old school way of composing through calculation is laborious and frustrating. If you know of a parallel PR, I'd be happy to put it to use. I've got work to do.

Also, there may be 2 ways to get the feature in, but the 3rd option us that the feature doesn't go in. It doesn't seem to have core development priority support, as it exists only as a closed PR.

[toto-polo]

It's indeed quite dramatic and surprising, given the progress in integration and the stability that the builds were starting to achieve. On macOS, my version is perfectly usable and communicates seamlessly with Jack. I've even managed to get an entire ecosystem of software working together, including Reaper, Ableton Live, Jack, Blackhole, Ardour, and Musescore Studio.

In a few weeks, I'll be recording one of my film scores with a symphony orchestra in Europe, which I composed using one of these builds.

This is terrible news for film music composers...

[cfirwin3]

It's indeed quite dramatic and surprising, given the progress in integration and the stability that the builds were starting to achieve. On macOS, my version is perfectly usable and communicates seamlessly with Jack. I've even managed to get an entire ecosystem of software working together, including Reaper, Ableton Live, Jack, Blackhole, Ardour, and Musescore Studio.

In a few weeks, I'll be recording one of my film scores with a symphony orchestra in Europe, which I composed using one of these builds.

This is terrible news for film music composers...

I don't think it is appreciated, the amount of professional work that was being done by some folks on this PR, in good faith that it was headed to merge.

If you are doing pro work and the entire workflow is abandoned, without a realistic alternative, it's devastating.

What's worse is the persistent knowledge that it can be done... but it won't be done.

[MarcSabatella]

Please read the preceding comments. No one is saying "it won't be done", just that it will make more sense to start from a clean PR. And if there truly is great demand for this, then as always in the open source world, someone will step forward. The large of large numbers applies here as it does everywhere.

Meanwhile, you are of course still welcome to use the existing build from this PR - it doesn't stop working just because the PR is closed.

It's still the case, though, that in the long term going forward, I think a native video sync solution will be far better than forcing users to rely on JACK. That's the path I would hope to see the core team pursue.

[davidhealey]

I think a native video sync

This is for more than just video.

[MarcSabatella]

True enough, but that's the main use case driving the demand. If you have other use cases in mind, I would recommend starting a discussion on the official forums at musescore.org to see if a consensus develop as to the best technology to incorporate to address them. JACK is a reasonable solution to certain problems on Linux, but is less so for other systems. Most likely there are better cross-platforms ways of addressing any use case that JACK happens to also address.

[davidhealey]

True enough, but that's the main use case driving the demand. If you have other use cases in mind, I would recommend starting a discussion on the official forums at musescore.org to see if a consensus develop as to the best technology to incorporate to address them. JACK is a reasonable solution to certain problems on Linux, but is less so for other systems. Most likely there are better cross-platforms ways of addressing any use case that JACK happens to also address.

The only cross-platform system I'm aware of that can do what JACK does is JACK.

ReWire never worked on Linux, and it's proprietary.
OSC doesn't usually handle transport sync so would probably require custom work for each host.
MIDI clock can possibly be used, but wouldn't work with Audacity or other non-MIDI tools like video players.

JACK seems like the perfect tool for the job.

[diedeno]

someone will step forward

I doubt someone will step forward, after reading this 18 months old conversation.

[cfirwin3]

Please read the preceding comments. No one is saying "it won't be done", just that it will make more sense to start from a clean PR. And if there truly is great demand for this, then as always in the open source world, someone will step forward. The large of large numbers applies here as it does everywhere.

Marc, we have talked passed each other on this issue since M4 released.
I fully and completely understand your position on the potential for things to happen.

My point continues to be that potential is not a project. To my knowledge, nobody is working on this now and the best work has been abandoned by the one working on it (I am assuming, for good reasons).

I don't disagree that a video player would be ideal. But I don't really see a good option on that front anywhere being worked on. I have seen Windows based VST video player options (that's a sore subject for Linux professionals) and a plugin that I am evaluating for VLC (more on that soon). But both of these do not achieve actual, seamless synchronization in the way that this Transport PR did. Those options are extremely 'hacky' and lack reliability.

Suggesting that there is potential for a better way... doesn't write film music. Also, the idea that 'if there is a strong enough desire for a feature, then a developer will take it on' is not true. There has to be a strong enough desire among developers in order for a developer to take it on. Case and point is that the developer on this PR didn't really use it for film/sync work himself. He just happened to notice the need for it, had an idea about how to get there, and offered up a lot of time to take a crack at it. That's a needle-threading prerequisite, not a guarantee.

It won't be done... until it is. And it may not... indeed, at this time, it is not. All research from this PR aside, we are at square one with no volunteers.

I'm saying nothing more than that. But I think my view is realistic.

Anyway, I am moving on to the VLC plugin to help that developer tackle possible solutions by running it through its paces. But if this PR gets revived in any form, or if anyone on here KNOWS that it is being ported to a new project... I want to know about it. I've got serious work to do, and Linux deserves to have a capable solution in Musescore, as it once did.

[cfirwin3]

The only cross-platform system I'm aware of that can do what JACK does is JACK.

ReWire never worked on Linux, and it's proprietary. OSC doesn't usually handle transport sync so would probably require custom work for each host. MIDI clock can possibly be used, but wouldn't work with Audacity or other non-MIDI tools like video players.

JACK seems like the perfect tool for the job.

Preach the truth, brother!
I don't think some on here are aware that Jack is the only cross-platform vehicle for this... and that it is maintained and used by other serious cross-platform applications.

Sure, it's complicated... but the work is complicated.
The alternative is a native system that speaks to related native systems: Dorico>Cubase / Sibelius>ProTools / MuseScore>nothing

But with this PR it was MuseScore>Blender,Ardour,Reaper, etc. verified on Linux and Mac, at least.

[diedeno]

But MAYBE there can be some hope after all.
Vst3 will come to Linux in one of the next builds, shared code from Audacity.
Perhaps MuseScore could also reuse the Jack code from Audacity. (unless jack is ditched from Audacity as well, one never knows)

[davidhealey]

Vst3 will come to Linux

That's good news, effects and instruments?

[cfirwin3]

But MAYBE there can be some hope after all. Vst3 will come to Linux in one of the next builds, shared code from Audacity. Perhaps MuseScore could also reuse the Jack code from Audacity. (unless jack is ditched from Audacity as well, one never knows)

Audacity does not support Jack Transport. I don't recall a time when it did. Sync is about Transport capability, not audio routing, which isn't really an issue, given the session managers avaliable.

[diedeno]

Vst3 will come to Linux

That's good news, effects and instruments?

Yes. But too late for 4.5

Audacity does not support Jack Transport.

Sorry, my mistake. I do not and never have used Audacity

[MarcSabatella]

It may be true that JACK is the only cross platform solution that does everything JACK does. But there may well be other technologies - perhaps not as well-developed or well-known yet - that can manage the specific subset of things that'd actually need.

Anyhow, while it's true that "potential for a better way" doesn't write filmn music, it is equally true that merging low quality and mostly unmaintainable code that is largely OS-dependent (and only works well on the least popular of the major OS's) into an already large and hard to maintain piece of software like MuseScore is just not a good idea. If you're unfamiliar with the dangers of unmaintable code, take a look at the story of a little music notation program called Finale.

As for the idea that having tones of existing technical discussion and code to reference would somehow make it less likely someone would volunteer to take that work and build on it - I don't know what planet that might be true on, but it's not this one. Having existing discussion and work to build on makes it easier, not harder, for someone to then take it from there. That's why, for example, we have things like mobile phones now but didn't in 1600, The vast body of pre-existing work leading up to the first mobile phone made it far easier for someone to build on than it would have been for Galileo or whomever to have invented it out of nothing.

So saying "All research from this PR aside, we are at square one..." is like saying, "all existing cancer research aside, we are at square one...". That's preposterous. The existing research is not aside, it's there.

[cfirwin3]

Marc,
Someone has to actually do something for it to matter. I'm a broken record.

[cbjeukendrup]

The comments above seem not very useful and are draining my goodwill a bit, to say the truth. I'll try to make the point clearer: if the PR stayed open, it would have been merged on the day that we would be 100% certain we'll be able to immediately do refactoring where necessary; now that the PR is closed, the feature will be merged on the day that someone from the in-house team takes it up. And those two 'days' are exactly the same day.

Yes, someone has to work on it; but that is equally true if the PR had stayed open. That someone is most likely going to be us, eventually (unless someone else is quicker).
Some audio driver work is planned for 4.6 anyway, and as part of that, we'll have to implement a proper way to select different audio driver APIs at runtime. That was one of the things that were not 100% satisfyingly solved in this PR.

Finally: I don't need to hear again how important this functionality is, because we've heard that often enough already.

[toadzrock]

It may be true that JACK is the only cross platform solution that does everything JACK does. But there may well be other technologies - perhaps not as well-developed or well-known yet - that can manage the specific subset of things that'd actually need.

Anyhow, while it's true that "potential for a better way" doesn't write filmn music, it is equally true that merging low quality and mostly unmaintainable code that is largely OS-dependent (and only works well on the least popular of the major OS's) into an already large and hard to maintain piece of software like MuseScore is just not a good idea. If you're unfamiliar with the dangers of unmaintable code, take a look at the story of a little music notation program called Finale.

As for the idea that having tones of existing technical discussion and code to reference would somehow make it less likely someone would volunteer to take that work and build on it - I don't know what planet that might be true on, but it's not this one. Having existing discussion and work to build on makes it easier, not harder, for someone to then take it from there. That's why, for example, we have things like mobile phones now but didn't in 1600, The vast body of pre-existing work leading up to the first mobile phone made it far easier for someone to build on than it would have been for Galileo or whomever to have invented it out of nothing.

So saying "All research from this PR aside, we are at square one..." is like saying, "all existing cancer research aside, we are at square one...". That's preposterous. The existing research is not aside, it's there.

It's not a case of "may be true", it IS true. Your attempt to diminish Jack's capabilities is not surprising, and not the first time.

All the rest of this diatribe is a massive exercise in whataboutism. "There maybe other technologies....." blah blah blah. There is ALREADY a technology that does all this, called JACK.

We knew when jack didn't appear in MS4, and a message of "we don't know when or if it will be included in the future" turned up in the long term plans, that linux users in particular were going to be behind the eightball, at Muse's behest.

This news is just more of the same. The effort required to include this pull request into main, and shape it to decent usability is no more than starting from scratch, AND JACK is seasoned and tested across all three major platforms over nearly two decades. It is mature, stable, reliable, sample accurate synced, etc....

Were it not for the herculean efforts of Lyrra, and Jojo-Schmitz (3.7+ and counting) among others, linux MS4 users would have little to no alternative to including MS in their daily workflow, seamlessly interconnected with other apps, with the mature, stable, reliable, sample accurate synced, cross platform, audio system that is JACK.

It is true that developers who offer (or buy) open source software have the choice of what they include in their app, and users either accept it or they don't.
It's also true that users have a choice as well, and as painful as a transition may be, there are alternatives, including forks of MS that still satisfy the user's requirements.

And then there's the freedom of speech, word of mouth comments outlining their experiences to actions and responses taken by owners/developers, and their most ardent supporters, favourably, or not.

Lyrra, thanks for trying with this massive effort. My continued respect to you and Jojo-Schmitz for not leaving linux users behind.

We won't forget.

[ycollet]

And just to add a little more information related to "Linux is not supported by the MS team":

• the musescore experience on Fedora is just a nightmare due to bugs not fixed for years
• where is native muse hub for Linux ?

[cfirwin3]

And just to add a little more information related to "Linux is not supported by the MS team":

• the musescore experience on Fedora is just a nightmare due to bugs not fixed for years
• where is native muse hub for Linux ?

It's really worse than that... the most updated Muse Sounds Manager (Muse Hub for Linux peasants) can only be gotten to by downloading the old MSM and then upgrading through the app itself (which has a number of 'administrator authentication errors' when doing so on some systems). Why isn't the current app on the main page?

Then there's the topic of cross-platform VST, effects, and native SFZ regression.

On sync, we now have a hacky VLC media player sync plugin that can work well enough. But mark my words, they will update the Plugin environment soon and kill that as well.

I wouldn't be surprised if there is a time when we get a video sync feature in M4... but I equally wouldn't be surprised if it's Mac/Win only (sorry, Linux. There's not enough of you. Thanks for understanding.)

I don't say these things to be negative. I say them to challenge the core development team to avoid doing negative things.

Which is better:
-Chase Dorico from way behind
or
-Be the only fully functional professional notation program that is truly fully cross-platform

The first option is a fool's errand. The second one, however...

[cfirwin3]

On the topic... here is a proper, complete tutorial for the VLC plugin that will have to keep us going in film scoring for a while:
https://youtu.be/trG2tiW5KRo?si=7Aw9s_4WylxBw3rv

[cfirwin3]

Here are some major updates to the VLC plugin. This is probably where it will rest for a while:
https://youtu.be/CqPaCBvov6o?si=luTstORowO_FeZ4d

[toadzrock]

Carl, thanks for the heads up regarding VLC.

…

On Sun, Mar 23, 2025, 17:22 Carl Irwin ***@***.***> wrote: Here are some major updates to the VLC plugin. This is probably where it will rest for a while: https://youtu.be/CqPaCBvov6o?si=luTstORowO_FeZ4d — Reply to this email directly, view it on GitHub <#19246 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BEUCOOIPPRMDP5YYWASA3QL2V3NSZAVCNFSM6AAAAAA4HICK5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBWGI4TMNRSGE> . You are receiving this because you commented.Message ID: ***@***.***> [image: cfirwin3]*cfirwin3* left a comment (musescore/MuseScore#19246) <#19246 (comment)> Here are some major updates to the VLC plugin. This is probably where it will rest for a while: https://youtu.be/CqPaCBvov6o?si=luTstORowO_FeZ4d — Reply to this email directly, view it on GitHub <#19246 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BEUCOOIPPRMDP5YYWASA3QL2V3NSZAVCNFSM6AAAAAA4HICK5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBWGI4TMNRSGE> . You are receiving this because you commented.Message ID: ***@***.***>

[andreimatveyeu]

To anyone who found this PR useful: I've created a containerized version to continue using it until something better is implemented: https://github.com/andreimatveyeu/musescore4_jack_docker

The docker image contains all dependencies and should not break as long as Xorg/Pipewire/Pulse stays compatible.

[toadzrock]

@andreimatveyeu
I appreciate your decision to provide a containerized version. Unfortunately for me, i've never used Docker, and wouldn't know where to start to use this.
I followed the simple instructions, and the ./build script asked for:

• docker

Where do i find this?

Alex.

Never mind. There's an additional challenge with qt6qml when building. I'm going to leave this and stick to 3.7.