Musescore 4 behaving like proprietary software

• Oct 6, 2022 - 11:15

It's been said in the forums that Muse sounds will be better than any soundfont, but if someone wants to use a specific instrument he can choose the soundfont in the mixer or use sfizz for sfz. However in practice it does not work appropriately.
If someone has a very specific soundfont, for example samples from the stops of a real life organ, it will not be a gm soundfont. But musescore 4 mixer does not allow us to choose the midi preset for a staff. So it's useless to load a specific soundfont on it.
I have a lot of effects plugins on my system that comes as ladspa and lv2. But musescore 4 does not recognize any of them because it's designed to use vst.
I can't also load sfizz nor liquidsfz because they are accessible via jack and musescore 4 cannot connect to jack.
I can't even connect to an outside sampler because musescore 4 cannot use jack.
The result is that musescore 4 behaves much like proprietary software that allows users to use only the solutions provided by the developers.
I understand that musescore team needs to earn some money selling some services to keep their good work, but please, don't prevent us from using open formats that could add diversity and creativity to our music.


Comments

On the matter of not being able to choose a soundpatch from a plain old sf2/sf3 soundfont; this functionality will be restored in a future 4.x update. There are plenty of use cases (even GM-ones): for example when creating practice mp3s for our choir, we never use the "Choir Oohs/Aahs" sound for them.

There are free SFZ VST3s out there such as Sforzando. Load the SFZ synth as a VST in MuseScore and you can use your SFZs still.

In reply to by jeetee

Thank you for your answer.
Indeed I have only two sfz instruments. Is it possible to load sforzando on linux?
Now, the real issue is that I have soundfonts of specific organ and harpsichord models. And what is a harpsichord or an organ if we we can't change the registers?
Anyway I'm going to keep using 3.6 until the changes are available at ms4.

In reply to by fernandoamartin

The word "yet" means just what it says - it means the support is not currently there but will be later. I don't see how working towards implementing Linux support can possibly be construed as "moving to a more proprietary like structure"? That's like saying a runner who is racing toward the finish line is actually "moving back toward the starting line". It's the exact opposite of the truth.

In reply to by Marc Sabatella

Sorry for the way I spoke. I'm glad some member of the team is sharing in the discussion. I remember that MS3.0 was released with some bugs and later the 3.x became the best ever. But, please, keep in mind the Linux community. Freedom of choice and customization is very important for us. When our distros update and throw MS4 on us, we can stick to 3.6 appimage, of course, but many of us like to try new features like the upcoming Muse sounds and the new audio quality. So it's important to keep up to date without losing important old features.

In reply to by Marc Sabatella

I have mentioned this elsewhere, several times (maybe several too many?), but the problem is with the optics of locking out rich Linux capabilities like midi timecode sync / Jack and then enabling VST exclusively for Mac/Win, while paying no attention to LV2 which is the plugin format native to Linux (and the plugins that true Linux music creators likely want access too). When searching github and the development forums, there is little to no indication of urgency regarding Linux specific resolutions to problems. Some forum entries (as with Jack) indicate a complete abandonment of concern and development. "Workarounds" that are offered (dubious scripts to enable Jack audio only... or suggestions to continue writing in 3.6) are demoralizing because they indicate a termination of any concern. Linux has been the hand that feeds and the current optics equate to a pretty painful bite to Linux folks that use this software to do solid, prolific work (particularly in media music).

We need the development team to show empathy and provide links to discussions on current development. All else is just lip service and the assumption of empty promises.

In reply to by kresimir

Since so many people use the program (a lot of students and hobbyists) the folks like you and I look like a very small minority that are asking for the proverbial moon and uncommonly niche features. But that's not true. Like I said, unless the developers are doing this sort of work, on Linux platforms, they aren't going to understand the importance of the features that we are talking about.
I see a whole bunch of active discussion about stuff like shortcut key mapping, mouse click selection and new articulation samples, etc... completely missing the forest from the trees.

In reply to by cfirwin3

Or, just people living in different forests. As you say, it is a pretty small minority of users who care about JACK, and a much larger majority who want keyboard shortcuts to work correctly. It's not that your particular use case isn't important at all, just that one has to start prioritizing from somewhere, and I think most people would agree that number of users affected is a very important metric here.

Meanwhile, also keep in mind that as an open source project, it remains up to the individual volunteer contributors to help implement features. Just because there happens to be a small paid staff, that doesn't mean it's fair to expect them to do everything. It wasn't the small staff of paid developers who did everything in 2013 and it shouldn't be in 2023 either. The open source community still plays an important role. It's been a bit weird in the lead-in to the initial 4.0.0 release, as there was some need to have cohesion during this unprecedented complete redesign and rearchitecture. But I fully expect things will settle down soon enough. it's been announced there will be further communiocation following the conclusion of the core team's own planning session this month. then it should become clearer what they are wanting to tackle themselves and what will continue to be left to the open source community as it has for many years.

In reply to by Marc Sabatella

I understand all of that. But the fact of the matter is that years-long significant development has been flatly remove and nobody is delivering the message, in earnest, that those features had vital application. Instead, we are getting persistent cover for the developers. What we need is someone to say:
"I hear what you're all saying... I will be the one to convey these concerns and the rationale behind them, even if I don't have experience with it or fully understand it myself".
I honestly don't think that current development knows the consequences to the removal of Jack sync. I think that there is an understanding that Jack, Alsa, Pulse is being replaced by Pipewire... without the complete understanding that those functions are not being eradicated, they are merely being emulated going forward. Jack sync (not merely the audio) is still very much active in Pipewire. Telling us that we don't have the full picture just confirms our concerns that development doesn't have the full picture, and nobody is willing to help them see it.
Just point me to the development forum thread that demonstrates a concern for these issues and I'll stop bringing it up.

In reply to by cfirwin3

The development discussion is generally not on the forum, but on Discord and on GitHub, and you're welcome to participate in discussions there - you don't need an intermediary to do so for you. Personally, though, as a volunteer who spends ridiculous amounts of time both here and there and has read and participated in tons and tons of discussions over the years, I am firmly convinced that the core development team is composed of highly intelligent people who understand things more than well enough. This isn't "cover"; it's my honest opinion informed by extensive first-hand experience.

In reply to by Marc Sabatella

I'm not taking a shot at their intelligence at all. They are brilliant folks that put out a remarkable and revolutionary play engine with a sample sound set that rivals thousand dollar plug-ins. What I am saying is, they can't know about what they don't do themselves. Scoring to picture is not a niche use of notation programs and they inadvertently took their superstar media composition tool (the only one available for Linux) to an unusable platform in the latest release. They can't know that if nobody on the team has used Musescore to score to picture before. If this were a temporary status then all of the threads on the subject wouldn't be closed in the blink of an eye as they are. Show me an open development thread regarding midi sync in M4 on GitHub. They are all marked duplicate or closed as far as I can see. Meanwhile, plenty of really superficial topics (almost all unrelated to the incompleteness of the Linux release) are getting high attention.

In reply to by cfirwin3

Dismissing the valid concerns of enormous numbers of users as "superficial" does not help your cause, and frankly makes continuing this discussion seem hopeless. And yet I'll try one more time.

Anyhow, if you had been following any of the discussions on Discord or GitHub, you would realize that no one considers scoring for video to be a niche use not worthy of further attention. On the contrary, it is considered vital enough to not leave up to the awkwardness of JACK but instead to be worthy of a more direct solution. It just hasn't happened yet, because, again, priorities. You're welcome to continue using MU3 for this particular purpose until MU4 is ready for that, but meanwhile, there was no reason to deprive the majority of people the use of MuseScore 4 as is, since it is more than useful already for most people's purposes. Nothing about the release of MuseScore 4 should be construed as a statement about the importance of Linux or of film scoring.

In reply to by Marc Sabatella

"Superficial" isn't dismissive, it's categorization. Please link to these discussion threads about the importance and development of picture sync in MuseScore 4 on Discord or GitHub so that we may read them and see for ourselves. I can't find them, I have looked.

In reply to by jeetee

Thank you for the category links, but to my point, the only discussion on there is conjecture from the months leading up to the release of M4. After that, crickets. A dead end. No discussion on development or attempts at implementation. To the contrary, all signs point to sync as being unimportant. Show me a link to a specific discussion to the contrary. I have already searched. The assertion is that there is some kind of vibrant discussion on this topic happening where the real business is shared (not in the musescore forum)... show me. I want to read them for reassurance.

In reply to by cfirwin3

There were definitely discussions, I remember them. I would ask that you simply believe me, but if you need to see the evidence, then simply keep searching.

As for the lack of discussion post-release, realize that most developers then took a well-deserved break. And then were focused on a patch release. And since then have been in planning meetings, and they've publicly announced that further communication about these plans will be forthcoming after the meetings. I really don't know what else you expect. You wanted them to announce their plans before the planning meetings?

In reply to by Marc Sabatella

If this were a priority, I would expect to see a GitHub entry on the topic classified by a developer as high priority. Developers do it all the time for a variety of regressions and vital features.

But the only GitHub indications are that the loss of Jack transport is unimportant and there are no projects committed much less prioritized regarding a replacement for lost capability. On the contrary most of the requests on this are closed or categorized only as feature requests.

I want to believe you, but I want to see developers putting some verbal weight into this issue somewhere. But I think we have established that there are no easy-to-find discussions on this, as has been suggested.

In reply to by cfirwin3

Dude, MuSc4 is essentially a brand new software in most ways and honestly because of that I'd probably wait to bring up or really push your concerns about Jack until they finish a majority of what seem to be bug fixes and most features advertised and promised in MuSc4 are working as smoothly as things did in MuSc3. Jack wasn't on that list unfortunately, and I don't think we can expect them to get to that right now. I think they need to fix what's there now more than they need to reintroduce a feature that will only bring in more bugs for now. In the meantime, yeah, some of us will have to keep on using 3.6 and if you really want to make sure this doesn't get forgotten. Come back every month or maybe every week if you can't bare it and remind devs about Jack so that as it gets closer to being something they can actually do, it's on the front of their minds. And also who knows, once the reintroduce plug-in development, it may be much easier to work on which is possibly a reason why that might be a higher priority right now. Harping on it not being a priority now is probably not going to change much in the meantime tho. Consistency will pay off. Just do little reminders and bumps, cause the tone of this discussion feels a bit too aggressive. It's not budging atm.

In reply to by speedmeteor101

"...and if you really want to make sure this doesn't get forgotten. Come back every month or maybe every week if you can't bare it and remind devs about Jack so that as it gets closer to being something they can actually do..."

This is exactly what I am doing. I am adamant (not aggressive) about it because it's not merely a feature request. It's a regression of long-standing function that is a baseline in notation software. I am mostly pushing back on the assertion that it is being looked at when all evidence suggests it is not. The assertion that there are bigger proverbial fish to fry is much more honest than saying 'oh there's discussion in the real development forums... go look there'

I'll keep coming back. But don't get annoyed with me... I have been a champion of the software since the very earliest days. It has been my exclusive platform for many years and I have advocated for it to colleagues and acquaintances. I am a friend of MuseScore and people like me should be listened to.

In reply to by cfirwin3

I don't disagree with the idea that you should be listened to because especially those of us who champion musescore to others (I include myself in that number since v0.9) want to be able to stand behind what we support in good faith.

Personally, I don't see it as a regression because I know it's intended and they just have a lot of work to do before they can get to it. Like many other features that have not been readded yet. And even though you may be returning to remind the devs, your frustration can be heard in the tone of your writing 😂. It seems like you're coming with an agenda and without understanding, especially from the developmental side of things. I don't think that those who have responded to you are in charge of Jack support, so it should be okay if there is something you don't agree with there. Just drop your reminder and unless your stance changes, let that original post every month or week be your voice, response, and opinion. As someone reading all of that which came before my response, your original purpose was becoming clouded by what was more or less an aim to prove others wrong.

It would be much more easy to understand and take what someone writes even more seriously when desires are concisely stated up front and left there without other things to distract from it. And I say this mostly because I agree with you and also desire Jack support (and am waiting for plugin support) but feel like this may exasperate things more than help move things along. And understand that things take time. I'm more of less thinking of MS4 as an incomplete or beta release right now because it doesn't have a few features I find critical and I find that it has a few more performance issues. But once it's given enough time to deal with the issues that are there, I'll definitely come back with reminders if it seems like they're trying to move past something I feel strongly about.

Perhaps I'm just worried that a valid point will get lost in 'the sea of requests' if it's brought up, but not at the best time or manner. So please humor me here. Let's be a little more understanding for now. Wait for the iron to heat up and then strike.

In reply to by cfirwin3

GitHub is being used to track actual bugs, not as a place for planning. There are separate design documents where overall plans are hashed out. Once a specific design is finalized for a given feature, then it is often posted to GitHub as a "task" to be used reference for developers, assuming it's something that won't just be handled by the in-house team.

Again, it's already been established that there will be an announcement shortly regarding the planning that is taking place this month and about procedures and how the team will be working with the community going forward. So, there really is no point continuing to speculate here.

In reply to by Marc Sabatella

In my case, I have been able to go on without jack exporting staves as midi files and playing them in whatever software I want. I understand that jack users may not be a majority, but Linux users, even not being the largest numbers of users, are considerable enough to be taken into account. Linux once was the home of Musescore and now is the least cared for in the development, the only one where some features doesn't work at all.

In reply to by fernandoamartin

Fernando: Yes. And this is a material observation, not an assumption.
But for sync, the big issue isn't moving midi data around, the big issue us with functional composition of music to picture without resorting to a legacy platform that will phase out.
-The lack of effect plug-in structure (or apparent lack of urgency) for Linux is observation 1.
-The fixation on VST (which is not native to Linux) over LV2 (which is native to Linux) in this endeavor... no wonder they can't get it to work. We have our own format, let's focus on that for the Linux build... observation 2.
-The removal of and general disregard for the very long standing and powerful Linux sync structure is just the icing on the cake.

In order for our conclusions on this to be changed, something formal must be said, or a release (even a buggy one) with added capability needs to come out quickly. But just saying, 'we plan to do X' with zero evidence of any X being done, much less discussed (while other Mac/Win centric items are)... what do people expect us to think? I don't think this perspective is the slightest bit irrational or presumptive. It's just what the evidence points to.

In reply to by cfirwin3

Remember LilyPond export? MuseScore used to have that, and it was removed for being difficult to maintain. It was a very useful feature I used all the time, since LilyPond produces the nicest engraving of all software.

I may be overly pessimistic, but I'm fairly convinced the JACK support is going to end up the same.

If I were more cynical, I'd think they are intentionally getting rid of features that work well with other Free software, and focus more on proprietary plugins, like MuseHub.

MuseScore is free, as in free beer. If you don't like what's available or it doesn't do everything exactly as you want it to, then don't use it - pretty simple, really.

In reply to by underquark

If what I wrote didn't make sense as Marc politely pointed out, that last statement makes even less sense. What team of developers would join, spend years writing a software, hoping to displease users and send them away to another software?
If Musescore is open source and has a forum is because they're willing to listen to users.

In reply to by scottlawrencelawson

That's the point. It is common for enterprise software developers to decide what to do in the next versions by themselves. But Musescore is open-source and has a community. I understand if they close the source of Muse Hub and, maybe, in the future, sell add-ons on it. It's their right.
But the base software is still open source and the community likes to share in the suggestions of its development and have customization available like in most open source softwares.

I'm getting the same feeling with MuseScore 4. Since it is licenced under GPL, it cannot actually be made proprietary. But newer version seems to get fewer and fewer features, there are new regressions like loss of support for JACK. New features are added into proprietary, closed source software like MuseHub. At this point, if you want nice playback, it seems you have to use proprietary software (even worse, MuseHub requires some shady service to be run with root privileges constantly).

Do you still have an unanswered question? Please log in first to post your question.