Bring back JACK support for proper Linux Modularity

Exactly.

In https://github.com/musescore/MuseScore/issues/12775 Tantacrul said:
"I'm moving Jack issues to 4.x, which is when we will begin to address them."

But now, it seems that the "community" (of Windows and Mac users) has decided that Jack is not needed anymore. (because it's way too complicated to setup, as i understand it)
"The Needs of the Many Outweigh the Needs of the Few" seems to be the general idea.

My comment was just that of another long-term Linux MS user (since version 0.x). Just what i think. MS is indeed the only relevant tool on Linux.

I really wish jack support can be reintegrated soon.

The MuseScore 4.0 release doesn't have all the components of earlier versions, JACK is just one of the missing ones. I believe the missing parts and some new tools too will begin to appear one by one, once the developers have cleaned the code of the current release. Linux is a strong platform of free software. By my opinion, MuseScore will certainly get JACK.

MuseScore and Tracktion Waveform are a good pair of linux software, but the great number of vst plugins keeps me on windows.

Bring a good selection of the most necessary vst plugins for free into linux and great many music producers will follow, then the commercial software developers.

I subscribe to these expressions of disappointment. I find it really unfortunate for Musescore to no longer allow Linux users to use Jack as in previous versions. I hope the message will be received!

This is a known limitation already being tracked on GitHub. See https://github.com/musescore/MuseScore/discussions/13745 for a workaround.

This really is not a valid workaround. It only routes audio to jack. But it does nothing else you can do with jack. e.g. midi routing or timecode for video sync, and so on.

I thought it was just me doing something wrong . . . . Linux JACK support is very important to me. I use Carla with WINE to host a bunch of VSTs, including Kontakt 7 which is required for a few sound libraries I've got. Note this howto: https://musescore.org/en/node/273531, and see the topic "Connecting via JACK (recommended)".

Bring back JACK.

If the developers aren't Linux users and aren't doing film scoring... then they won't get it. Musescore is the only serious option for notation on Linux. For years, it was an extremely capable tool for film scoring because of its integration with Jack transport. All of the major Mac and Windows proprietary notation tools that Musescore is supposed to rival utilize some sort of rewire capability and/or onboard video player for sync.
I have an audio lecture that Bernard Herrmann gave (in the 60's) regarding the place of film music in the work of a serious composer. He rightly regarded film score work as a staple of composition and suggested that every composer should do at least a little bit of it. Here it is, archived online:
https://youtu.be/m4sWB7uew3Q
As I attended graduate school for music composition over 20 years ago, I noted that every single composer in the studio worked on at least one film project, on their own, outside of their instruction and studio work. Most of us scored multiple films during that time and continued in that work well after.

In this regard, Jack transport and/or video sync is a necessary tool for Linux users... It doesn't matter if the platform can't be applied to Mac and Windows, just as it doesn't matter that VST and effects support aren't available for Linux while it is functioning on Mac/Win. If cross platform means equal treatment... then make it so. Frankly, it seems to me that being cross platform in this sense will require a couple of forks to really make the software most usable. If Mac/Win get VST, then Linux should get LV2. If Linux gets Jack (or even just simple midi timecode sockets) then Mac/Win can get the same in their rewire format.
OR!... we can just recognize that "equal" isn't the definition of "fair" and allow platforms like Linux to retain their basic benefits while other platforms are permitted to have their own (like VST), etc.
We are pleading and begging here for the urgent return of some pretty basic expectations that have existed for years. We are begging. Otherwise, we are merely left with a 'hot new sports car' of a play engine that simply can't be used without jumping through a whole bunch of long-antiquated "hoops" for the work that we do.

That workaround:
https://github.com/musescore/MuseScore/discussions/13745
is only for audio. Jack is a rewire/sync platform that communicates midi timecode. The option posted here accomplishes none of that communication with Jack. Without access to the midi timecode coming from M4, Jack is merely rendered an audio output platform (for which there is really no point, as audio can already be routed using other tools without Jack). The folks that see this as a usable workaround don't really understand how Jack is used by Jack users.

Workaround should be listed as "NO". The implementation is not even partial and fails to utilize Jack for its purpose.

A few years back Jack was a pain to install and configure. Which made it both a nich use case and a pain to develop and test.
But today jack support is ready out of the box on main distributions using Pipewire (fedora and ubuntu at least). Which makes it both easy to test and develop and usefull to a larger amont of user.

I won't uprade without Jack support, which i found sad because from what i tested i like what has been done on musescore4.

I depend on Jack transport for the work that I do with musescore and would be disappointed if this feature did not return in a future patch. For what it's worth I'm also a musescore pro subscriber. The ability to work with Jack transport to synchronously drive musescore together with other software was a primary motivation in choosing to support Musescore via paid subscription.

It is being asked for time and time again

I would say that the reasonable rule to guide the development of MuseScore would be to first serve the many, later the few. Another reasonable rule would be that the few must be reasonably many to have their needs served. So does any one have the numbers of windows/mac/linux users and the number of jack users?

"Il est fou de confier au nombre la garde de la liberté". Georges Bernanos dans La France contre les robots.

I don't have the numbers, but have some recollection of numbers posted a couple years ago, there MuseScore for Windows was some 70%, for Mac some 20%, for Linux less than 10%

Probably.
MusesSore has 5 million users (dixit Tantacrul https://www.youtube.com/watch?v=XGo4PJd1lng ).
So half a million Linux users.
Just what is the mission of MuseScore (MuseCy)? Selling subscriptions on musescore.com?

If I remember correctly, the percentage of Linux users was initially 100%.

Well, that was before Lasconic joined, well before version 0.9x, some 15 years ago

If I remember correctly, MuseScore has a 100% share of music composition on Linux. It's the only option, people. The fact that so many Windows and Mac users get to use MueScore is a gift from Linux. Heck, the fact that so many people have android devices and Chrombooks is a gift from Linux... The very day to day operation of the Internet is largely gift from Linux. Let's not make priorities on platform market share. Could we just take major regressions seriously and avoid them like the plague? Certain regressions, like the one discussed here, have way of bringing work to an absolute halt. Some of us aren't merely hobbyists and we have invested enormous amounts of time and resources to keeping our work in Linux. Then the rug gets pulled out from under our feet with the only solution being the use of a legacy build that the company doesn't believe in anymore and won't support in the future.

It's also worth noting that rewire and sync is pretty standard on other platforms. Jack in Linux is the environment for that. Likewise, Jack is not on its way out with Pipewire emulation... just the opposite. Jack capabilities have never worked better with so little intervention than it has since being emulated by Pipewire. Jack sync is the yesterday, today and future for rewire capabilities on Linux (and some without the experience of working in Jack simply aren't aware). I can tell you that if M4 gets a rewire feature on Windows without Jack support... a big chunk of Linux users will go "nuclear". But I suppose it doesn't matter if they account for less than 10% of users, right?

Where's that eyeroll emoji... I know I left it around here somewhere...

No workaround

This thread won't really be a good place to get answers from the design or development team; this site is more community-based. The development discussions happen on GitHub and Discord. That said, as a long-time volunteer on the project (and a Linux user myself), I'm happy to give my own perspective.

First, there is pretty much no chance that the number of Linux users within the MuseScore community currently is anywhere near 10% - likely closer to 1%. And even within that small subset of Linux users, only a small subset of that small subset actually do anything that would rely on JACK. That doesn't mean these users aren't important, but it's surely a much smaller number than the "half a million" figure being tossed about.

Also, no one - absolutely no one - is being "aggressive" toward Linux users. I am a Linux user myself, as are a number of the other developers and designers. Again it's just a matter of priorities and whether it was a good idea to hold up the release for the vast majority of users who don't rely on JACK just for the sake of the small percentage who do. JACK would have to wait anyhow, as implementing it in the new architecture would be a huge job. The question then becomes, is it fair to ask everyone else to wait also? That would be an aggressive act, I would say. The vast majority who don't need JACK can enjoy MuseScore 4 today, and meanwhile, those who do rely on JACK can continue to use a version that works for them. Going forward, the open source community can work toward a solution as it always has. Everyone wins.

And for the record MuseScore is not the only software for music composition on Linux. LilyPond and the various systems built around it also have a very large following (for good reason), and there is also a variety of DAW software.

Anyhow, it is clear that a large number of users - not just Linux users, not just people who currently rely on JACK - would benefit from some sort of synchronization. So it seems clear that this should be a priority. Whether it happens to be accomplished via JACK or by other means (e.g., a built-in video player) is an open question for continued discussion, and I suspect the design team already has ideas there. But whatever the solution is, I would hope it would not be something that is Linux-centric, but one that is truly cross-platform.

"Il est fou de confier au nombre la garde de la liberté"

Free software is an ideological movement and MuseScore is part of that movement, no doubt. But that lofty statement is a shot high over the goal. MuseScore with jack or no jack has nothing to do with any noble Liberty.

It would help if those in command would publish a roadmap of further developments.
I simply cannot believe there are no plans.

But in the MU4.1 project on github, no trace of jack. Nor VST for Linux.
Since only 1% are Linux users, it seems logical

See https://github.com/musescore/MuseScore/issues/11689#issuecomment-113192…

Although our new plugin sampler will work for Linux, VST support is something we will include in 4.1. This will correspond with other VST features that are necessary for high-quality playback.

And https://github.com/musescore/MuseScore/issues/12775#issuecomment-123325…

I'm moving Jack issues to 4.x, which is when we will begin to address them.

Closing until 4.0 is released, after which, I'll reopen.

Sure, that's what Tantacrul said.
But no trace in https://github.com/musescore/MuseScore/projects/63

The talk of VST integration is a bit of salt in the wound for Linux as it implies a conformity to a non-native plugin format. We have a robust library of .LV2 effects and instruments that we don't want to ignore for complex and janky implementation of non-native plugins that we don't otherwise use.

What percentage of Finale and Sibelius users work with rewire sync?
The number is probably smaller than the share of Linux users that use Jack.

Nonetheless, rewire is essential to notation programs in their most high profile uses apart from engraving for publishers.

The concept of percentage lead priorities is wrong-headed.

Lastly, there is one sentiment that is always more destructive than aggression... and that is neglect. A published road map solves this. Hearsay is not productive in the de-escalation of concerns.

Yes, it has already been announced that plans will be published after the meetings this month.

Sad to see the comments that Linux users are few and hence don't matter that much. imho Linux makes a far greater impact in the software world than the number of desktop users implies. I've been using Linux for years and have made good use of Musescore 3.x. However now due to the lack of Jack I can't use 4.x. My fellow musicians are on 4.x and I cannot use the scores they are creating for our joint work. I've been forced to dual boot to Windows to work with them. Windows updates are already causing PC problems and I have spent far more time on win problems than I care to because of this decision by MS. Consider the responses you would get if you took a decision that forced MAC users to use Windows. Please reconsider.

I'm confused. Are there Linux distributions that provide no other way to use audio other than JACK? That's not the norm, and I'm using MuseScore 4 on Linux (Debian) completely successfully. If your particular distribution for some reason refuses to support any other audio method and blocks all attempts at installing one yourself, I'd recommend simply switching to a more full-featured and open Linux distribution. No reason to resort to Windows. After all, MuseScore doens't support JACK there either.

I can't answer for the previous poster, but I don't think the issue is merely about audio output. Jack is not needed for audio output and the "workaround" that was initially posted for Jack support only provided audio connection (which isn't exclusively what Jack does). The previous poster may be conflating the Jack issue, re: timecode routing, with the additional complaints, re: a lag in Linux feature implementation and what looks like a potential restriction on Linux development to only implement Win and Mac features (VST).
On this topic, what he says is true. A collaboration on projects requires Linux folks to dual boot or work in Win VM to load projects that utilize missing features (unrelated to Jack).
The larger argument is that Linux has become proverbial 'chopped liver'.

Still waiting patiently on those imminent development updates that some are hedging their bets on! 😉

Just warning, it's going to be rough if the next news release and road map doesn't prioritize getting Linux features congruent with Win/Mac development (at the very least).

I get why some percentage of users - on Linux as well as on other systemns - used JACK to enable certain synchonization features. What I don't understand is how lack of those synchronization features somehow renders MuseScore completely inoperable on Windows as the person to whom I was responding seemed to be implying. or how switching to a different OS that also lacks JACK support would somehow fix it. So I am actually suspecting they simply hadn't tried yet, and somehow misread this discussion as suggesting MuseScore just wasn't supported on Linux, which is of course not true at all.

The only missing feature I know of that might at first glance seem to require one to resort to Windows for in order to collaborate is lack of VST support. But that's a bit of a red herring as well. You can still collaborate even if you end up hearing the sounds differently. I guess it depends on the unique noature your specific collaboration.

The poster would have to clarify, but I would bet that your last statement is the issue for him. I have had this collaboration problem with students since M4. It does change the sounds, but this is an issue when trading files back and forth. I just don't think that any recommendation for a user to merely dual boot (a recommendation that I know you aren't making) is a realistic solution. That's quite a 'sledgehammer' answer to the problem.

Personally, I would prefer that the distribution releases lean into the capabilities of their respective distributions rather than take the approach of a level playing field or a rule by popularity with respect to features. To that end, I agree with you regarding the limitations in file to file collaboration across distributions. Such limitations are not new just because Linux development is behind. I'm merely suggesting that the lag makes the optics poor and the recognition of 'problems' inflated. Someone in development really needs to break the silence on these issues soon.

I came on here to find out where selecting JACK had been hidden in MS4 only to find out that support has been deprecated - what a massive backward step.

I confess to having only skimmed through the thread so I might have the wrong end of the stick here but here's why I pretty desperately need jack support: I'll often be writing backing vocals and my preferred method is to record the tune and then improvise the BVs and then notate what I've written. With MS3 I can have ardour going via JACK to do all the recording I need and then have MS open too with the sound outputted properly via jack and also jack passing my midi keyboard through to MS so I can quickly switch and notate what I'm doing. That won't work with MS4 because JACK hogs the sound output so that MS won't play and because MS doesn't see JACK I also can't use an external midi keyboard - don't get me wrong I can still use it just not hear it or input from an external device. And, yes, when I'm not using JACK MS works exactly as you'd expect but that's still a pretty big let down for me. I can think of quite a few other use cases too.

Are you running Pipewire on your system or are you using the actual Alsa, Pulse and Jack engines?

You 'might' find that Pipewire emulation allows you to run everything simultaneously... which us why Jack isn't going away and why it is more powerful than ever as the rewire platform for Linux that it is. Pipewire is the future.

I keep preaching from my soapbox but I fear that some folks have their 'Jack is dead' blinders on (because they don't really know the diverse applications that put Linux on par with Mac/Win rewire capabilities).

On Windows, the goal is to have everything sync with Cubase or ProTools. On Mac... Logic. On Linux... Ardour or Qtractor. It's a serious need for serious musicians on every platform. So many top line Linux music tools work only on Jack. M4 is a kick in the face to the Linux workflow and pipeline. I really want to showcase their hot new play engine... but they created far too many hoops to jump through with the removal of Jack to make it worthwhile.

Insert a call for patience and a reminder here about upcoming announcements (without any apparent knowledge of their content). Instead, we need a messenger to the developers to say, "hey guys, you might want to browse this thread and consider the arguments".

I just read through the Berklee Master Of Film Music resource prerequisites
.pdf here:
https://tinyurl.com/yc77fpk6

Like Blender in Linux satisfies all industry grade software for animation and VFX (some studios and degree programs actually use Blender now)... there are capable Linux alternatives for everything on their list, except for the notation category.

While M4 could easily help to satisfy the instrument library requirements, it can't be used outside of the M4 platform. VPO, Versillian, and other libraries can handle that. But, when it comes to notation, M3 is the only capable option. M4 isn't capable enough due to the lack of sync with the other software that Sibelius, Dorico and Finale have. But M3 is dead and no longer an option going forward.

Drumbeat, drumbeat, drumbeat, drumbeat...
The current philosophy on Linux/Jack at MuseScore is misguided and unaware. It even prevents the new, marvelous play engine and library from being showcased in many instances.

Hello,
thank you developers of MS4, great work !
except that the missing JACK support kicked me back to version 3.6
It's a pity !
I'm using it with Ubuntu Studio, together with hydrogen for drum automation and so I need jack for synchronization.
Please bring back Jack to Musescore !

It's been weeks... and weeks now. No announcements (which were suggested to have been imminently coming, weeks ago) that I have seen regarding a road map forward on Jack. No mention of work on missing capabilities on the Linux version either (missing mixer/effects capabilities of any kind/format). I don't think a call for 'patience' is a valid recommendation any more. The reluctance to directly address plans on these issues (unless I have missed an announcement somewhere) is deeply disappointing and seemingly confirming for suspicions that many of us have.
Not to say that I don't appreciate bug fixes and a more stable composing environment. But how hard is it to say "We have a plan to implement X,Y, Z in Linux... it will be done and it will work" OR "We will not implement X, Y, Z in Linux without community development branching for that platform"
It's not like they don't have an opinion on this. They just aren't sharing. I can't find a single post on the subject since a vague mention to investigate options that was posted prior to release.

Iceberg! Dead ahead!

If you head over to GitHub, you'll see that over the past week or so, they have indeed been posting issues and/or tasks outlining the plans for 4.1. It's still a work in progress, which is why they aren't announcing firm plans for other features before there are any - what would the point of that be?

Once again, if you wish to engage in discussions with the developers, the place is GitHub, not here. The reason they haven't responded to you is that you haven't actually asked them. You've only asked fellow users here on the defunct/obsolete musescore.org issue tracker that has been retired.

I haven't seen any GitHub discussions on the topics in question. Please post a link if you know of a recent update. Would love to read it... not so much interested in searching for a needle-in-a-haystack mention of Jack or LV2/VST, however.

As for the defunct/obsolete issue tracker, why is it still there? Other portions of the Musescore enterprise that have been called defunct and obsolete (like Jack services) have been removed. Why leave up a forum area that calls for input only to be redirected by a moderator to post issues in the "proper place" as if the poster is the one in error? Lock the forum and put a notice at the top with a link to the appropriate forum venue for issue tracking. Why leave it open?

As for why would I post on the .com forum? Because that's what it's for. It might not be where developers are looking (they should, because it is THE .com space that users are called to) but it is also where users can see sentiment that they resonate with. It's a place to vent.
If it shouldn't be a place to vent, if it isn't a place where developers check, and if it is merely a redundant location to get help from users, then why have it?

There is nothing new GitHub about this specific topic, but lots on other topics relating to 4.1 planning. The point being, things are being actively posted as there is information to share. I would think people interested in the subject would be sufficiently motivated to find and follow discussions there. Thwt would be one way of establish whether this is truly important or not.

As for this issue tracker, it's still here to be able to research history of issues. But it's not intended to be used any more for new issues, which is why the links are is removed from the main menu structure of the site. The developers decided quite some time ago to focus on GitHub instead - this was long before the release of 4.0. Maintaining two separate trackers wasn't working for anyone - not for the developers who would then miss issues, not or users who would perceive their issues were being ignored, and definitely not for folks like me trying their best to help users and developers alike and having to resort to copying information manually from one place to another.

Not sure what you mean about "the .com forum" - I'm not aware of any such thing, and I certainly didn't mention anything like that.

I agree with cfirwin3 and understand exactly what he means about this being the .com forum. What he means is that if you google musescore issue tracker you arrive here not anywhere near github. If you google musescore help or musescore manual or anything like that it's here you get to. This is the public face of the musescore community and the community will come here first and therefore it would make sense for devs to keep one eye on it. I mean certainly if you think of, or if I think of at least, the users that I know on non linux platforms most of barely any of them will have even heard of github. For myself I am that fabled desktop linux user who is not a technical user - I'm on the terminal very seldomly, I'm going to delay upgrading from ubuntustudio LTS xfce version as late as possible because I don't want to spend time learning KDE: the level of activity that I can bring to a community is getting into forums and kicking some where-with-all to projects when I can - when I have a question or issue my first port of call is to google the project's forum - maybe I've been conditioned by canonical back in the early days to believe that the forums are where you get help or learn the answers to your problems.

Sorry, I was confused, since of course this is musescore.org, not musescore.com. It's true the forum on musescore.org - not this defunct issue tracker, but the actual forum - is a good place to discuss MsueScore with fellow users. So yes, a great place to get help in general, but not the place to track issues formally.

Unfortunately, it's hard to control what Google shows when you do searches. I can merely report the facts - this issue tracker is retired, and that is why it is removed from the menus. It presumably will stop showing up in searches too over time, but that's up to the search engines. But anyhow, when reporting bugs, please use GitHub.

If there were unlimited resources in the world, then ys, there would be enough developers and enough time to monitor multiple locations for issues. But as it is, please let's all do our best to simplify things and follow the procedures.

Please bring back Jack support. Jack transport is very useful for me and I have to stick with MS 3 for now (I've try MS 4 and it is awesome)
Thank you

I've just installed version 4.1 and am very disappointed to see that jack support has been dropped. My particular use case won't work with anything else and I'll have to stay with version 3. Please implement jack in version 4.

I'd been putting off installing and testing 4.1 to avoid the disappointment of JACK not being back. I figured if I didn't see it, it didn't necessarily not happen.

I also need Jackaudio support to be able to use Musescore on Linux for my needs. Please could we have an update about if/ when there are plans to implement this? Thank you!

See https://github.com/musescore/MuseScore/pull/19209
and
https://github.com/musescore/MuseScore/pull/19246

So should be fixed in 4.2

That's fantastic news, thank you.

But this is only jack audio. If that is fantastic, good for you.
You can already do this now. See https://github.com/orgs/musescore/discussions/13745
Most jack users will want jack midi, jack transport -- the complete jack functionality - and midi time codes.
But, for sure, it's a step in the right direction.

I hadn't appreciated that it was only audio, so not as fantastic as I thought.

Hopefully, now that jack is partially integrated, the next steps will be easier and come quickly.

But is this integration of Jack Transport (Sync) or just audio routing? If it doesn't include transport/midi, then I doubt that this will actually be viewed as a fix for most that articulated that they wanted Jack support. I never needed audio routing in Jack as a main audio out has always been available without it... it's the sync and midi that folks want Jack for.

There requests for JACK have come from two types of people - people using Linux distributions on which JACK is the best way to do audio, and people on both Linux and Windows who want a way of synchronizing MIDI between applications. Linux users naturally think of JACK as the way to do this because it's the main supported way on that platform, but Windows users are just as likely to want other synchronization methods. So fart there haven't been a lot of macOS users weighing in on this.

My sense here is, supporting for JACK audio is good for that first set of people - those for whom JACK is simply the best way to do audio n their particular distribution.

My sense is also that being able to synchronize MIDI between applications is definitely important - especially for things like film scoring, integrating with DAW software, etc. But it's not inherently more important for Linux users. So a solution that works across all platforms is better than one that's really only useful one one or two. If someone ants to volunteer to implement JACK MIDI synchronization, I suspect that would be considered for merging. But it won't really solve the MIDI synchronization for 90% of users. So the main focus really should be on solving the bigger problem here.

Again, my personal feeling only; I have no actual say in any of this. I'm just speaking from a common sense perspective of how the development team could spend their resources in a way that is the most beneficial to the most users, while not excluding anyone. MIDI synchronization is important to solve, but I have real concerns that JACK will only solve it for a small minority of people.

Marc, you and I have gone back and forth on this plenty... so that's not my goal here. I just want to point out that talk of an alternative is barely "talk" at best. I know of no serious routes being considered for development for an alternative to resolve sync capability. If someone knows of one, please point it out to me so that I can go aggressively jump on that band wagon. So I am very wary of the inclination to hold off on Jack support in favor of a merely wishful-phantom-universal solution when a history of development and implementation already exists for a proven infrastructure like Jack.
On the point about universal implementation... again, that argument is really sour with Linux folks. There is currently a fairly slow-walking, underdeveloped, or entirely ignored set of features that Linux users have been left out on. Nobody is holding off distribution for us... because why should they? I think the same should be for Jack (unless someone out there actually has a proof of concept for something to replace it). The universal-fairness argument isn't really compatible with the nature of cross-platform software. Many applications have different treatments over their cross-platform implementation, sometimes on significant features.

I've got 6 film scores lined up right now. They will ultimately include some rendering from M4. But I want to demonstrate that M4 is fully up to the task, competitive and THE "go-to" solution for at least 1 platform. It's a hard sell to say "This program sounds good... and in the right hands it sounds great! But film scoring requires some stone age procedures and a number of 'hacky' hoops to jump through in order to get there"

I say... let's get this Jack thing done (as it had already been done before) and then deal with bringing more universal alternatives to the foreground as they occur. Honestly, sync may be a matter of implementing a different solution for each platform. That kind of thing isn't unheard of (as is the case with plugins).

One other point that I scratch my head over is the assertion that Jack audio (just audio) is a primary or an exclusive concern for many (or even just some) folks. As it stands, I can open M4 and route the audio any way that I like using its ALSA master output via Carla or some other patchbay. It's not like MuseScore has ever been an audio input/output kind of tool. It has really only ever been a player (audio or midi). Removing Jack prohibits zero audio routing capabilities that I can see. I am having a hard time envisioning a need for Jack specifically that isn't anchored to the need for transport synchronization and/or midi signal routing. I wonder how many of the folks that were on board for the Jack audio (only) sync request were aware that "audio" was the only consideration understood in that request...?

TEST:
I just fired up M41.1 (no Jack) and Qtractor (which is a JACK ONLY DAW on Linux) and via Carla Patchbay, I easily recorded M4's ALSA stereo output to Qtractor's JACK stereo input. I was then able to immediately play back Qtractor's recorded track.
I am using Pipewire on Ubuntu Studio 20.04 LTS. But from what I understand, most distributions are implementing Pipewire by default.

Unless I am missing something... the implementation of JACK audio-only is... as they say in the news...
a "nothingburger"

We don't really need Jack for that purpose and we haven't for a while.

Again... unless I am missing the forest for the trees and overlooking a common audio use that requires Jack audio-only, it seems like audio-only implementation is a waste of time and effort UNLESS it is an intentional means to the end of implementing midi routing and transport sync.

To be clear, there has been a vocal contingent specifically saying that JACK audio is important them, independent of MIDI synchronization concerns. I get that you are not part of that contingent. but please don't dismiss other people's valid needs just because they don't apply to you.

So given that this need exists, implementing JACK audio is an important step, because it brings those systems up to parity with the rest of the systems that don't require JACK audio to work well. Achieving parity is a nice first step, and then we can worry about the next steps of implementing new functionality - MIDI synchronization - whether achieved by JACK or some other technology that is more useful on other platforms, or a combination of both.

Just because it hasn't happened yet doesn't mean it isn't on the radar. But it won't happen faster if time is first taken away to work on a solution that only benefits a small percentage of users. Which is why to me marking it as a community project is absoojtuely positively the right decision for the MuseScore community as a whole. If some Linux user wants to implement JACK MIDI, great, then Linux users can have synchronization before the rest of the world, without delaying the eventual general solution that the majority would benefit from.

Please don't mischaracterize my posts. I wasn't the least bit dismissive. I tested out the current setup through Jack ONLY audio systems without Jack available on M4, showing that such a need is already covered via the current audio output. This setup is either standard on Linux systems or available for configuration. I am asking... with absolute sincerity, for someone to describe the scenario that requires audio-only jack support. I am also wondering (out loud) if some (and perhaps many) of the folks that are on the Jack Audio implementation wagon aren't presuming that midi and sync are part of that development... and perhaps this audio-only support is being misunderstood and potentially misrepresented here. That's why I am showing capability AND asking for an example of need.

You wrongly called me dismissive... while being dismissive. Don't you see it?

The statement I called dismissive is "Unless I am missing something... the implementation of JACK audio-only is... as they say in the news...
a nothingburger. We don't really need Jack for that purpose and we haven't for a while." I stand by that statement.

But I am not dismissing your desired for MIDI synchronisation in the slightes.t I am 100% fully embracing. i want you to have that feature, I want to have that feature, and I want every single other MuseScore user to have that feature. I want to find the most direct path to that goal, with a minimum of platform-specific detours.

Surely if someone were here insisting developers spend their time developing a Mac-only solution that then delayed a solution for Linux, you'd be arguing against that?

"Unless I am missing something" gives an awful lot of room for response, which you aren't giving. What is Jack audio-only trying to accomplish? What is the need? A simple case study? What I am finding is that I can't seem to determine one that isn't already achievable with the current audio configuration.

Answer it or don't answer it... but don't chop me down for asking and challenging the request.

Regarding your question about Mac over Linux... three letters... VST. We're still waiting and every time someone opens their head about waiting... SOME people consistently paint them as being impatient.

But back to the issue. What use is the Jack audio-only configuration trying to achieve (and please don't give me some vague comment about system connection)? Is there anyone on here in that camp? Marc apparently isn't. But I really want to hear from someone that is so that we can run a couple of tests together.

I stand by the statement that we don't need Jack to do something that we can do without it. How is that dismissive?

For me just the fact that I can have MS4 open and using the same audio back end as all the other things I have open is smashing. Without jack support if I'm in ardour or kdenlive or obs or whatever and then need to switch to MS4 I'm having to close whatever that is I'm using in order to stop jack in order to go into Ms and then do what I'm doing there and then restart jack and open up whatever it is that I was doing before.

Also if MS can use jack then it benefits from the incredible routing options for example being able to route the audio from MS straight into ardour or into outboard plugins or whatever I think is a great option to have.

1. Simultaneous operation of M4 along side Jack apps without shutting down.
2. M4 routed to Ardour with Ardour running Jack.
3. Similarly Routing M4 to Jack only plugins.

Do I have that right?
If you see above. I did this with Qtractor earlier today (which is absolutely Jack meaning that it can't run on Alsa or pulseaudio like Ardour can). Pipewire emulation replaces the Jack and Pulseaudio backend with the intention to creating a seamless environment. Working in Pipewire has eliminated the need for all of the backend configuration that Jack used to require.

Let me run some tests with Ardour.

Are you on Linux and are you running Pipewire?
If you aren't on Pipewire, be aware that it is becoming the default audio service on most Linux distros and it's worth investigating for that reason alone.

I'll return with results.

Granted, I didn't also respond to your afterthought about "unless I'm missing something", just to the primary point being made. I have a limited amount of free time to volunteer helping people, so I try to prioritize on what's most important.

Anyhow, we can continue to quibble about inconsequential and finger pointing, or actually focus on problem-solving. As already pointed out numerous times, this issue tracker is defunct. There is no possible purpose in posting here to this thread further, so I won't be doing so any further. If someone wants to start a discussion about positive steps that can be taken , feel free to do so in the correct venue.

Marc, the only positive steps on this issue is what I am presenting. I am demonstrating that folks that want audio from M4 into Jack apps and plugins can have it right now.

I recorded a quick video showing it and will post soon.

Here you go:
https://youtu.be/3LpXu1-wvlA?si=Mvqxwmu0XSVfZuc5

M4 running not only along side Ardour (running on Jack) but also through Ardour (running on Jack). Recorded with OBS.
Pipewire is the answer to all of this... not a limited iteration of Jack in M4.

M4 needs Jack for transport and midi... it doesn't need it for audio.
If you think this is me being "dismissive" then you need to go check out what that word means. It's just how things actually are right now. Telling people over and over again that a fictitious alternative to transport and MIDI is better than Jack (which is here and now) is being dismissive. And telling Linux folks that they aren't the priority while simultaneously propping up the importance of an obscure singular feature that isn't actually needed (see the video) is being dismissive.

Just want to ad my 10 cents to this: MU4 is unusable for me without the audio support MU3 had. So I'm stuck on MU3 until this gets resolved. Is there any sight of beta code to test?

I cannot express how MS4 poisons the life. It constantly doesn't do core notation software functionality. Something, that I believe was conquered already up to the 2.0 versions.
But on the very root level ‒ it just doesn't work normally on Linux.

It plays with awful latency
I can not even connect the keyboard to it. It does not see midi-through port and immediately crashes if I try to connect to any other device.

The reason for JACK is ‒ that you never think of all these things. Not from the developer side, not from the user: developer just provides socket and user connects it to what he needs.

MS4 just does not work. Only two things it does: shows pretty pictures at the home tab, and renders scores with Finale fonts (the thing I installed it for).

MS3, oppositely, has a lot of ergonomic and logic in interface as well as good stability. And I'm pretty sure, this is ergonomic, but not my habit, as I'm not really an everyday MS user: I also work with Finale, Sibelius, and notation in DAW. In MS4, things are really on the wrong places and behave wrong. I wish I just had a MS3 + Finale fonts.

But most of the things, lack of just simple input ability and audio response just kills…

cfirwin3 , Pipewire actually works much worse for any sort of audio production. I'm not sure it will finally be as versatile and useful as Jack, but the just initial idea of running every interface in every domain simultaneously makes a lot of CPU work.

And it is not possible to have alongside pipewire and normal blocking ALSA, which is usually used for JACK. Blocking ALSA is really matters, as well as it comes with ASIO on Windows systems. And I don't see any reasons to build an entire environment around noticeable slower pipewire, just for the notation software. Which is an important part, but not a heart of audio production.

Especially, if the previous MS version works perfect.

Success with Pipewire likely depends on your system and your version updates. But really, that part doesn't matter as there is no such development that caters to Pipewire. The way forward is to develop the necessary port of previous work done for Jack in Musescore. The Pipewire users like me can utilize the Jack Transport feature and traditional split Linix audio service users can work the old way. My video was made because some folks were regularly reminding everyone that the current work being done on Jack was only for audio (which is hardly the low latency prone part) while simultaneously saying that Jack is not the way forward... that some imaginary solution was better in the long run. I was just showing that pure audio connections can be had now, and I don't put stock in imaginary things. Things are built today with the building blocks of today. That means that full Jack support is the only worthwhile endeavor in Musescore 4 right now (in the absence of an alternative coded idea rather than a can-kicking ideal).

I wish I just had a MS3 + Finale fonts.
MuseScore 3.7 has Finale Fonts. And any other Smufl font you want.
see https://musescore.org/en/node/347645

Oh, that's interesting, thanks! But I've already made a crutch by myself: https://github.com/Levitanus/MuseScore/tree/3.6.2

I was excited to be able to use the new Musescore and its sounds, but after reading this discussion I fear that Jack Transport will not be reintroduced, so I am disappointed and desperate!

First off I love Musescore, I'm a pro member and gladly will keep paying, but the whole point of Jack is having a MIDI clock output. Jack allows for this which is crucial for film composition and makes transcription a whole lot easier. Just being able to bridge audio to Jack is not really a workaround nor very useful. Come on guys, we REALLY NEED THIS!

It should be "top shelf" priority if Musescore is a serious notation program.
There is community development, but I see no administrative interest in the way of incorporating the pull request and branch work on this that is out there. The Lyra branch that focuses on Jack is sitting with many elements built, verified and pushed... but admin doesn't seem to care. They should not only be anxious to get the work incorporated, they should be facilitating it with their own contribution. Otherwise, Musescore remains an affordable entry level notation program that sounds amazing, but can't be used seriously for media music composition. I'm willing to jump through a bunch of hoops to use it for film score because I choose to be on Linux and I have no alternatives without giving up Linux (and my right arm and left leg). Most folks will not be willing to bother with the required workarounds. Jack is a serious project that is perpetually made integral to other serious projects (like Blender and nearly all Linux audio software). The sentiment that Jack is not the best way forward is frankly ignorant, especially given the work on Pipewire emulation that is now becoming the long term standard for Linux audio. There isn't a better alternative given... and seeking an alternative is only an argument rather than a serious endeavor.

Just. Put. It. Back. Where. It. Belongs.

It's so obvious.

Finally!
This branch achieves Jack Transport and audio routing. In this way, applications can be synchronized for film scoring and/or for the integration/mixdown of midi instruments in DAW. There are no controls for channel assignment and midi output as before in M3, but frankly, the mere implementation of Jack Transport makes that capability somewhat irrelevant due to the complimentary capabilities of a synchronized DAW:
https://github.com/musescore/MuseScore/pull/19246

Here is a demonstration:
https://youtu.be/pnpYIGULBEQ?si=jbVws_TlUIzZV1X5

This branch is developing quickly and is built upon the most forward iteration (4.4 while official release is 4.2.1). Create an account at github and download appimage builds from the Checks tab.

-Carl

This is excellent news!

With the 3 series of MuseScore, I used MuseScore in the creative phase of projects and for arranging with the DAW, it was pure golden. I'm looking forward to using MuseScore synched and hooked up with the system with low latency again.

Workarounds are no options because they almost always are flow killers, so this is very good news! :-)

You still won't be able to control midi channels.

Not with this branch. But we will have sync. As of now, there really are no midi channels as the playback is a play from notation engine. I recommend a project to incorporate a translation from the play engine to midi data via the mixer. This concept appears to already exist as a translation to VST plugins in Mac/Win, so it doesn't seem like a huge leap to satisfy midi streaming in this way. No takers on the concept yet, however.