End of Life plan for 3.x ?

• Ян. 13, 2023 - 03:15

I've been using 3.6.2 and it works fine for my simple needs; I'd rather not upgrade to 4.x.

I did some searching, but can't find anything mentioning how long support ( mostly interested in security fixes ) is planned for 3.x

Is there a support plan for 3.x?

thx
-tom


Comments

In reply to by Jojo-Schmitz

Yeah, you definitely shouldn't stop support for 3.x.
1. It works on older machines.
2. It is fine for most 'old-school' composers, who don't use the computer as an aid/crutch to composing but us the computer as a pure notation tool to write already composed music.
3. It uses, what I suspect is the 'old code' that may be disorganized, but has 7 - 10 years of updates from users and programmers embedded into it.
4. It cannot be integrated with Musehub and is the last stand alone pure compositional aid.

I hope you can become a power to be and override this decision.

In reply to by knoike

I do have forked it (and do accept PRs to it, see https://github.com/Jojo-Schmitz/MuseScore/tree/master-to-3.x). But in my fork none of the GitHub CI (Continuous Integration) things exist, those are the ones building the artifacts, and also used to generate releases.

Setting up all that stuff, and possibly a separate site for distributing and supporting it, is something I currenlty don't fancy doing. So currently I just lean on the existing infrastructure.

In reply to by Jojo-Schmitz

I see. I understood that the your forked project is centered on code repositry.
I also understood that I need to build it myself to get an executable binary for the time being.

I have some question.

0.
For convenience, I think the your repository/branch may need a unique and easy-to-call name.
For example, like "FRJ (forked repository by Jojo)" or "FCJ (bugfix collection by Jojo)".
Do you have already any idea?

1.
Where is the issue tracker for that repository/branch ?

2.
May I distribute the executable file I built for testing purposes?
Especially, to Japanese users.

In reply to by knoike

Every developer of MuseScore works on his/her own fork (only those that have write access to the MuseScore would not need to, but generally do too).
And no, you don't have to build it yourself, as PRs against the MuseScore repo are build for you (or me in the case of that {PR #9000 for a 3.7](https://github.com/musescore/MuseScore/pull/9000)
You would hoewver need a GitHub account in oder to be able to see and download the CI artifacts

0.
My fork is https://github.com/Jojo-Schmitz/MuseScore. The branch with those changes for 3.7 is https://github.com/Jojo-Schmitz/MuseScore/tree/master-to-3.x, as I created a PPR from it (https://github.com/musescore/MuseScore/pull/9000), I can't rename it anymore

1.
My fork/repo doesn't have an issue tracker, because I haven_t created one. Not sure whether I want to...

2.
Yes! You can distribute your own ones as well as the artifacts from my (or anyone's) PR, there's nothing that could prevent you from doing this

In reply to by Jojo-Schmitz

Would a 3.7.Jojo be possible outside of musescore.org, e.g. a 64-bit Windows installation available on Github? I have seen the Github artifacts for 3.7 but I don't know how to install them. MS3 clearly has much life in it yet so it would be really nice to see bug fixes and security patches. Maybe it could continue for many years and become "Musescore Classic". Surely this would not need official approval.

In reply to by knoike

I was just looking for an easy upgrade path. I am not familiar with CIs, PRs and nightly builds but will try to figure out what to do with Jojo's mention of using bin/musescore4.exe to update my 3.6.2 installation. Perhaps there are detailed instructions on Github somewhere.

In reply to by knoike

From https://github.com/musescore/MuseScore/pull/9000 to "Show all checks", then to "Details" of the platform you're interested in, here the latest for Windows: https://github.com/musescore/MuseScore/actions/runs/3980051855/jobs/682…, there to "Summary" https://github.com/musescore/MuseScore/actions/runs/3980051855 and there you'd find the artifacts for 64-bit, https://github.com/musescore/MuseScore/suites/10512391754/artifacts/521… and 32-bit, https://github.com/musescore/MuseScore/suites/10512391754/artifacts/521…

That gives you a .zip file, inside is a .7Z file, inside that a MuseScore-3-7-0-xxxxxxxxx directory, extract that, inside that go to bin, there you'll find MuseScore3.exe.

Yes, it is a bit of a pain...

In reply to by yonah_ag

I could reproduct it.
No plugin required to reproduct.

[Plugins] -> [Plugin Creator]

In the Plugin Creator
[File] -> [New]
[Run]

Running…
Creating component failed
line 1: plugin cannot be loaded for module "QtQuick": Cannot load library C:\Users\ (account)\Downloads\MuseScore\MuseScore_x64_4104872289\MuseScore-3.7.0.4104872289-x86_64\MuseScore-3.7.0.4104872289-x86_64\qml\QtQuick.2\qtquick2plugin.dll: 指定されたモジュールが見つかりません。

Tested Env.
OS: Windows 11 Home 22H2
MuseScore version (64-bit): 3.7.0.4104872289,
revision: 095932d

It did not occur in Ver. 3.6.2. it ran successfully.

In reply to by Jojo-Schmitz

I've extracted the x86 artifacts and plugins now work. :-)
Now it's so easy to apply correct guitar "Let Ring" that I probably won't bother with my Excel plugout.
Thank you for the note length fix in PRE and plugin API, this really improves my workflow.

Note: The plugin uploaded above has a bug which stops note length adjustment - Ooops!
I'll upload the fixed version to GitHub with a few enhancements just in case anyone wants to use it.

In reply to by knoike

That C:\Users\ (account)\Downloads\MuseScore\MuseScore_x64_4104872289\MuseScore-3.7.0.4104872289-x86_64\MuseScore-3.7.0.4104872289-x86_64\qml\QtQuick.2\qtquick2plugin.dll looks quite long and has MuseScore-3.7.0.4104872289-x86_64 in it twice?
And that message doesn't match the one from the image you shared earlier

Try with reducing the length, by copying/moving that last MuseScore-3.7.0.4104872289-x86_64 toC:\Users\ (account)\Downloads` and run from there

In reply to by Jojo-Schmitz

It doesn't seem to be a problem of path length or location.

Running…
Creating component failed
line 1: plugin cannot be loaded for module "QtQuick": Cannot load library C:\MuseScore-3.7.0.4104872289-x86_64\qml\QtQuick.2\qtquick2plugin.dll: 指定されたモジュールが見つかりません。

Jojo, please try to manipulate following procedure for artifact MuseScore-3.7.0.4104872289-x86_64:

[Plugins] -> [Plugin Creator]

In the Plugin Creator
[File] -> [New]
[Run]

In reply to by Jojo-Schmitz

I tried the following.
It works fine.
I think the cause is in "qtquick2plugin.dll" included in artifact.

copy
qtquick2plugin.dll
from
C:\Program Files\MuseScore 3\qml\QtQuick.2
to
C:\MuseScore-3.7.0.4104872289-x86_64\qml\QtQuick.2

[Plugins] -> [Plugin Creator]

In the Plugin Creator
[File] -> [New]
[Run]

Running…
Plugin Details:
Menu Path: Plugins.pluginName
Version: 1.0
Description: Description goes here
Requires Score
Debug: hello world

In reply to by Jojo-Schmitz

Jojo, excuse me, please try following procedure.
If that situation doesn't give you any error, it is strange.
I'm guessing that the Jojo's environment is loading the DLL from another location.
(It's probably loading from the folder set in the environment variable PATH for SYSTEM/USER.)

1.
In MuseScore-3.7.0.4104872289-x86_64\qml\QtQuick.2,
rename "qtquick2plugin.dll" to "qtquick2plugin.dll.5_15_2".
(or delete "qtquick2plugin.dll")

2.
Run MuseScore-3.7.0.4104872289-x86_64\bin\MuseScore3.exe

3.
Manipurate MuseScore 3.7.0
[Plugins] -> [Plugin Creator]

In the Plugin Creator
[File] -> [New]
[Run]

Get an error as follows:

Running…
Creating component failed
line 1: module "QtQuick" plugin "qtquick2plugin" not found

NOTE:
"qtquick2plugin.dll" is not exist
-> "not found" error.

"qtquick2plugin.dll" is exist, but cannot load
-> "cannot be loaded" error.

In reply to by Jojo-Schmitz

Maybe I am wishing too much, but as Donna Summer said: Dreams come true for those who dream.
I am using MU4 because of Muse Sounds, specially Muse Strings. I like most of the other features of MU3 better than MU4. Would it be possible to borrow some code from MU4 into MU3 playing system to allow it to play Muse sounds too?

In reply to by Jojo-Schmitz

Maybe I am wishing too much, but as Donna Summer said: Dreams come true for those who dream.
I am using MU4 because of Muse Sounds, specially Muse Strings. I like most of the other features of MU3 better than MU4. Would it be possible to borrow some code from MU4 into MU3 playing system to allow it to play Muse sounds too?

In reply to by Jojo-Schmitz

This idea is OK. There's no need to start a new site now. It would get a long time to attract users. Keeping the information and talks at musescore.org and github is enough. And keeping Musescore classic side by side woth Musescore 4 is also enough. Users could jump from one version to another without as needed. In my case, I write many things in 3.6 and when I need a feature of 4.0 I "save as" my score with a new name and go on in 4.0. At the end it is just a matter of mixing the audio results in a DAW.

In reply to by fernandoamartin

No! Please don't do this.

I'm sure that MS4 will eventually have the missing MS3 features, and porting such a huge change is likely to impact MS3's stability. I think that MS3 (MuseScore Classic) should remain the pinnacle of MS's .SF2 based notation systems and move to a maintenance model. If users are really keen to see extra features then the plugin api would provide a route. Improved sound can be achieved by using exported MIDI with a DAW.

In reply to by fernandoamartin

no, Muse Sounds are a proprietary, binary-only feature that deliberately undermines the Open Source-ness of the rest of Mu͒seScore and indicates removal of any attempt of the current team to improve the base code’s audio capabilities (in fact, they’ve documented they removed some features, with mu͒3 as base).

In reply to by mirabilos

There's a muse-hub.COM site that suggests that they will sell plugins in the future. I understand it's their right since they are creating the plugins in their own costs. However many features existing in 3.x were removed and nobody knows how many of them will return. Some like the very limited sfz support were announced to be removed. Others like bringing back choice of presets in soundfonts are promised to return. After all, if we need some feature from 3.x the only way to secure it is maintaining it.

In reply to by Jojo-Schmitz

Jojo-Schmitz,

Respect and Thanks. I've just D/L and run 3.7-64bit linux version (aka 3.6.3 "Musescore Classic") appimage from Github, and it works well, so far, including Jack audio and midi. (Which is why I tried your version. I can't see Jack being added to 4.0 linux in the near future, if ever.)

Alex.

Crash report, sort of—
On Windows 10, the 64-bit flavor of build ca30ecd crashed every time I tried to open the demo files 'Brassed_Up' and 'Dynamic_Strings,' without any message or dump file etc--just crashed and disappeared. (It did successfully open 'Dawn.') Before trying to open other demo files, I switched to the x86 flavor, same build, which had no trouble opening all three files. I then switched back to the 64-bit and now the same demos opened just fine.

Just guessing here, but I wonder if the problem had to do with the dialog that asks whether you want to use Leland and Edwin. When the 32-bit presented me with that dialog I checked the box for applying those fonts automatically to older files. I noticed that when the 64-bit opened 'Brassed_Up' and 'Dynamic_Strings' they were showing the asterisk indicating unsaved changes. I assume both flavors are using the same settings—and that because I had set the default in the 32-bit, the 64-bit bypassed the dialog, and applied the font updates without having to ask.

(Which leads to a question: Where are settings like that stored? Is it possible to have different settings for different development builds/versions, and if so, how?)

In reply to by Stephen Cummings

I can't reproduce, loading these scores in my self-built 64-bit 3.7.0, which should be e9183eb, from today.

That setting is in Edit > Preferences > Import

I can't recommend that automatic conversion though: it also looses the Jazz style font (like in Brassed_Up)!
It really should only replace Emmentaler with Leland (and Free Serif with Edwin), but replaces all fonts.

In reply to by knoike

It might be related to the plugin issue mentioned further up, as that dialog is qml code and sure enough uses Qt Quick too.
Would explain why the 32-bit version is not affected and why the 64-but version is not affected anymore once that dialog got disabled via Preferences. And why I can't reproduce this too

In reply to by Jojo-Schmitz

Hi Jojo

MS3.7 gives this warning (Linux)
[....] Sample(Trombone F5) start(0) startloop(12406) endloop(12659) end(12666) smaller than SoundFont 2.04 spec chapter 7.10 recommendation
[...]
This with the appimage as well as my own build.
Warning from sfont3.cpp
I ignore if it there are any consequences because of this.

In reply to by graffesmusic

I think it is cause of SoundFont you use.
In the specification of SoundFont 2.04, there is the following sentence.

> Thus dwStart must be less than dwStartloop-7, dwStartloop must be less than dwEndloop-31, and dwEndloop must be less than dwEnd-7.

In SoundFont you using:
endloop(12659)
end(12666)
->
12666-7 = 12659. the 'endloop' value is 'equal' not 'less than'.
The 'end' value is only slightly smaller, so MuseScore may have showed a warning instead of an error.

In reply to by knoike

Unfortunately, almost all existing soundfonts violate that part of the spec; I talked to s.chriscollins about it, and he said it’s not been a problem in practice, and he’ll probably take care of these for new instruments but can’t bother for old ones.

Yes, it’s only a warning; FluidSynth upstream plays these fine, and the bastardised derivative thereof in use in mu͒2 and mu͒3 “probably” plays them fine.

It’s not a regression (change relative to a previous version) anyway.

In reply to by graffesmusic

ad 1: yes, they are the same soundfont basically anyway (one’s a subset of the other), but others are also affected

ad 2: that’s because the logging is either not present there or hidden as a nōn-development build; the problem has always existed, but the code that outputs the warning is recent (I wrote it as part of fixing some soundfont-related crashes)

In reply to by Jojo-Schmitz

Just bumped into this upload failure myself and then noticed these comments so I simply did the upload again via 3.6.2.

3.7.0 is a game changer for me because of the limit on PRE and plugin API maximum length being increased from 2000 to 60000. (64000 would be actually be even better because a 1/64th note could be made to ring for 4 beats of 4/4 time. It won't affect me in practise because I don't have scores with notes shorter than 1/32nd but it would just feel 'tidy'. I'm nit-picking – I really appreciate 3.7.0).

Maybe there needs to be a forum page for MuseScore Classic.

(or even MüScore Classic if the MuseScore name is not allowed).

In reply to by yonah_ag

> Maybe there needs to be a forum page for MuseScore Classic.

I think so, too.
For the time being, It may be a good way to create a new topic every problems/issue with "MuseScore 3.7.0:" at the beginning of the title as you did in the "Development and Technology Preview" Forum.

In reply to by mirabilos

There is no particular reaosns Muse Sounds shouldn't be discussed here. Absolutely nothing about the software license for MuseScore, absolutely nothing about the terms one agrees to when creating an account on this site, and absolutely nothing about the guidelines for what qualifies a site for a ".org" domain in any whatsoever makes this even slightly out of the ordinary.

In reply to by Marc Sabatella

> They don’t even get the line between .org and .com right
Well the folks here were talking about the name for ms3 future releases, but,
I definitely agree the .com .org vagueness is totally uncalled for. How much resources could it possibly require to rename .com to something else? Considering .com is a sharing site "not intended to sell user generated content, but to provide a community", like a focal point for musicians, like a hub, how about renaming it to www.musehu.. wait a minute.

If you think this is obscene, how would you feel about if there's a future musehub.org site? for sharing free and open source custom instruments like a free equivalent of spitfire labs, but to use them you must download through and use with musehub.

In reply to by msfp

Changing a product name is a pretty big deal - to pull it off and not alienate customers or lose marketshare in the confusion probably costs a significant amount of money. Not saying it can't be done or might not ultimately be worth the substantial short-term cost, but imaging that one can just change a product name with the push of a button and expect no downside is not realistic.

I subbed here to stay abreast of if/when MS3.7 moves out of development mode - if that's the right notion of what this is all about. Until MS4 SIGNIFICANTLY matures, I'm a MS3 devotee. Kudos to Jojo & all associated.

My PR #9000 has just been closed and with that no further artifacts (AKA development versions) will get created unless and until I get help to set up the GitHub CI actions/workflows on my fork.

Last artifacts for

These will stay there for only a limited time, IIRC for 90 days (starting yesterday, 27 Feb 2023)

In reply to by Jojo-Schmitz

If I am correct, two things should be needed and enough to get workflows working:

  1. Ensure that actions are turned on for your fork (go to your fork's repository page, click Settings→Actions→General and choose the option "Allow all actions..."). Now the Actions tab should appear at the repository page.

  2. Change workflows settings so they are triggered for your branch. For this you should change these lines to something like

on:
  push:
    branches: [ master-to-3.x ]
  pull_request:
    branches: [ master-to-3.x ]

This should of course be changed in all .yml files in that directory which need to be enabled. At this point workflows should start after pushing or making a pull request to that branch, not sure if they will work in their current state or they will require some extra variables defined in the repository itself.

Also those scheduled nightly builds (these lines) might need to be disabled if they are not necessary, but they would definitely not break anything if they are kept enabled.

In reply to by dmitrio95

Thanks!

Now I'm stuck with

error: Not valid build mode: 
valid modes: 
  devel_build - build for developers, usually builds on pull request
  nightly_build - build for testing current development, usually builds once a day
  testing_build - build for testing before release (alpha, beta, rc), usually builds manually
  stable_build - build for release, usually builds manually

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