End of Life plan for 3.x ?

• jan 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

Megjegyzések

• feb 15, 2023 - 19:25

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.

Reply

• feb 15, 2023 - 23:36

> 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.

Reply

• feb 19, 2023 - 18:41

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.

Reply

• feb 21, 2023 - 12:57

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.

Reply

• feb 28, 2023 - 10:48

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)

Reply

• feb 28, 2023 - 19:18

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.

Reply

• feb 28, 2023 - 20:03

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

Reply

• már 4, 2023 - 12:10

Can I fork your repo with the potential of generating PRs that could be incorporated or would this have to become my own custom version? I want to enhance the TAB capabilities with features seen in other guitar focused software, e.g. TablEdit and Guitar Pro.

If it became my own version then I would still want a means of including your on-going enhancements.

Reply

• már 7, 2023 - 11:17

I think the problem seems is in
https://github.com/Jojo-Schmitz/MuseScore/blob/custom-fonts/mscore/pref…
line 1652.

// selectScoreFontsDirectory
//---------------------------------------------------------

void PreferenceDialog::selectScoreFontsDirectory()
{
QString s = QFileDialog::getExistingDirectory(
this,
tr("Choose Score Fonts Folder"),
myStyles->text(),
QFileDialog::ShowDirsOnly | (preferences.getBool(PREF_UI_APP_USENATIVEDIALOGS) ? QFileDialog::Options() : QFileDialog::DontUseNativeDialog)
);
if (!s.isNull())
myScoreFonts->setText(s);
}

should be
myScoreFonts -> text(),

Reply

• már 11, 2023 - 11:44

No, I'm just a parttime and umpaid volunteer ;-)
The fix numbers do related to issues (or sometimes forum posts) on musescore.org, or on GitHub (prefixed with a 'GH')
No idea what that ENG means it was, back in the day, a nomenclature used by the internal developers and their internal tracker

Reply

• feb 28, 2023 - 21:22

To Jojo and all other contributors: many thanks for 3.7!
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (32-bit): 3.7.0.4281504283, revision: e7f64b5 works fine. But in the 64-bit version the palettes of the basic and advanced workspace don't appear on my screen.
No problem of course: for 3.6.2 I use the portable version which is 32 bit.
The Script Recorder seems a nice addition and an invitation for further study of https://musescore.org/en/node/278278

Reply

• ápr 30, 2023 - 14:20

PS: Is this still the right place to post issues related to your (wonderful) 3.7+? Seems like things are quite active with your project, but there haven't been new posts on this thread lately. So if issues should go on GitHub, please give specific instructions/link. (I see that the Issues page on your GitHub repository is empty, and I have no idea where to look next.) Thanks.

Reply

• máj 13, 2023 - 04:32

Hi Jojo, I just found you're part-time actively working on your own fork and I just managed to install it.

I am not sure if this is the latest release (attaching image). I am aware of some of MS4 new features, MuseSounds, etc, but I am just still more convinced by this version because of many aspects, one of them being the disappearing of the "piano-roll". It is nowhere to be found (or at least I have not found it) in MS4 (yet?), which allowed me to "nuance" some sections more precisely as well as doing some other tricks. I do like the layout of 3.x more, but I understand 4.x may be better for the majority of people.

So in summary, thank you.

Csatolmány Méret
Captura de pantalla 2023-05-13 052600.png 4.23 KB

Reply

• jún 12, 2023 - 03:05

I have noticed that progress has been made in MU4 regarding the implementation (for both playback and engraving with no workarounds) of multi-measure repeats. Allegedly, there is going to be a fix ready for 4.1.

• https://github.com/musescore/MuseScore/issues/10922

I have also seen this post that does relate to this (and there is a long conversation about multibar repeats):
• https://musescore.org/en/node/21649

Would you be interested in backporting it, if possible?

Kind regards!

Reply

• máj 13, 2023 - 06:09

All I want to say is "THANK YOU"! I stumbled upon this and have been running 3.7 on Linux for several weeks. Works like a charm. I definitely prefer 3.7 to 4.2. In fact, I bought Dorico when I thought I might be forced to go to 4.0.

The ONLY thing that I like about 4.x is that it does do a slightly better job of score layout. To my ear, the sounds are not worth the hassle of all the things that they broke or left out entirely of 4.x. And even the sounds that are good enough to use are only useful for a very limited range of musical styles. On top of that, the "powers that be" seem to have decided that Linux users are not worth their time and trouble!

Reply

• máj 15, 2023 - 18:35

For some reason my pallette window isn't loading (using the master pallette for now, that one works fine)
Is this a known issue or is it something on my end?

Reply

• jún 20, 2023 - 16:25

Hello Jojo. After about 6 months many issues in muse sounds were corrected and now it's usable. But I often stumble at a situation where I want to use muse sounds as a realistic orchestra but want to add some sfz or soundfont with staff text to change presets on the fly at the same piece. In Linux it's not possible to connect mu4 to any other software. So it would be good if I could write the piece in MU4 to make the larger orchestral arrangement and tgen open it in MU 3.7 to use the features not available at MU4. It's not practical to start a file in MU3. 7 just to play with one or two instruments and then configure a whole orchestra manually at MU4. It would be much easier to take an orchestral template at MU4, write the piecw and port it to MU3 to use sf2 and custom sf2 in some few instruments. And doing so by exporting musicxml loses some data from the original score.
Would it be possible for you to implement backward compatibility from MU4 to MU3. 7?

Reply

• jún 20, 2023 - 22:13

I imagine that full backwards compatibility won't be possible as MU4 adds new features. But what if you unlock MU3.7 to avoid it identifying a MU4 score as from an early version? I mean MU3.7 simply opens the score, regardless of what version was used to write it, and then we see if at least it preserved the notes, tempo changes, symbols etc, in their place. Of course, making the fine adjustments would be up to us users.

Reply

• júl 23, 2023 - 22:42

Hi Jojo. Thank you so much for continue supporting MS3 as 3.7.X. That might be a very valuable job for millions of users. I tried it out on a windows-10 system with version 5544645636, but unfortunately I then detected the following two problems:
1. NO Palettes and NO Plugins in the Windows x64-Version supported (see screenshots in ZIP below)
Note: Only in the Windows x86-Version the Palettes and the Plugins are present and ready for use.
Could it eventually be one or more DLL-problems not supporting 64 bits?
2. NOT hiding empty staff after crescendo lines before (see screenshots in ZIP below)
If a crescendo line or hairpin ends just at a measure before the next few empty measures in a staff should go hidden, then the hiding fails. After deleting the hairpin or shifting to left (so it doesn't end at the end of the measure before), the hiding will work.

Would be nice to analyze the issues above and possibly find a patch for those.
Thanks again and kind regards, HeinzVo

Csatolmány Méret
Detected Problems MuseScore-3.7.X.zip 2.45 MB

Reply

• aug 7, 2023 - 13:52

I tested the artifact MuseScore-3.7.0.5784330917-x86_64.
It seems to be resolved the problems.
In my environment, all palettes are shown correctly.
And, the plugin creator works fine.

Was it caused by a missing Qt5QmlWorkerScript.dll ?
Maybe Qt splited or changed its DLL configuration provided by Qt in some version of Qt.

Thank you for your good job!

Reply

• aug 7, 2023 - 14:26

I tested the artifact 3.7.0.5784330917-x86_64 as well and yes, all the palettes and plugins will show correct, but:
Now the header and footer texts are misplaced and overlap at the left side of the page. Also switching Header-text on/off will unexpectedly shift down the whole score, causing unnecessary page breaks.

Csatolmány Méret
MuseScore 3.7.0.5784330917-x86_64_Header-Footer misplaced(1).png 208.33 KB

Reply

• aug 7, 2023 - 15:45

Now tested the reverted version MuseScore-3.7.0.5786034942-x86_64:
Header-/Footer-Texts truly are no more overlapped now, Footer is correct displayed, but Header switching from OFF to ON still shifts unexpectedly down the whole score, causing 49 instead of only 43 pages to be rendered as done in MS3.6.2. So issues #128, #140 and #150 a) are really solved now (many thanks), but issues #150 b) and #141 are still a problem yet for the correct 43 pages rendering.

Csatolmány Méret
Gloria_in_D-major_Vivaldi-RV589_00_Alle-Teile_Tenore.mscz 169.59 KB

Reply

• aug 7, 2023 - 21:14

Underneath the activated header text there appears an unnecessary empty white field in MS3.7 that then shifts down the frame/music below. This empty extra space on the page then causes unwanted page breaks through the whole score, making header texts unpracticable. Could that unused empty white stripe below the header text again be removed as it was in MS3.6.2?

Reply

• aug 8, 2023 - 15:20

Yes, unfortunately that's true. But I think we should not gear to the quite buggy MS4, but rather to the very stable MS3.6.2.
Could we open at least a feature issue for harmonizing to MS3.6.2 if you don't think it's a bug, although that behavior is really very ugly and impractical for a well done page layout to be converted to nice PDF-sheets?

Csatolmány Méret
MuseScore 3 (3.7.0 unstable)_with Header overlay - useless white ribbon appears below header occupying page space (mark).png 256.68 KB
MuseScore 3 (3.6.2)_with Header overlay page displays correct.png 264.89 KB
#150_Windows, 32 & 64-bit Header text overlay creates useless white gap occupying page space.zip 1.36 MB

Reply

• aug 8, 2023 - 16:36

But this is NOT a usful backport because it rather seams to be a bug in MS4 that should be bugfixed, so falling into the first category...
NOTE: for Footer-text the implementation is absolutely correct and works well - only for Header-text the implementation is quite different, strange and extremly unpractical. Why not do the same implementation?
So does that mean for peoples only Footers may be used (also in any future releases) and Headers causing that really very strange page layout should be omitted in any case?

Anyway thanks for proofing all that.

Reply

• aug 8, 2023 - 16:43

Report it as a bug in Mu4, let's see whether it really is. And if it is and gets fixed. I'll backport that fix

But before that fix header text does 'invade' the title frame. Not good.
Headers can get used, they just take some space now, to avoid invading the title frame (and the upper musical border)

Here how it looks in 3.6.2:
bar.png
And here is how it looks in 3.7 for me:
foo.png
Clearly an improvement, won't you agree?

Reply

• aug 9, 2023 - 16:04

No I do not agree:
In 3.6.2 you can easily configure the y-offset of the header-text (relative to the page margin) in positive AND negative direction (so you can also shift it above the music-area - try it out with a small negative value enstead of zero to shift it up).
But in 3.7 you do NOT have that full flexibility (positive shifts works but do not make sense because also bleed into the frame and negative shifts do NOT work as wanted because of creating such a space consuming unwated banner: therefore shifting up to a good place is NO MORE possible in 3.7). So it's effectively a regression and makes the app less flexible for page configuration!
In 3.6.2 only there is the full fexibility to configure a good page layout including headers by setting a useful (negative) y-offset to shift the header ABOVE the page margin. The same behaviour we have at the footer to shit it BELOW the page margin here with a positive y-offset. Isn't that simple and nice?

Reply

• aug 11, 2023 - 00:34

MuseScore 3.6.2 (and earlier) required the ugly hack of forcing the user to artificially inflate the size of the margin to account for headers, then the even uglier hack of applying a negative offset to place the header within the margin, just to avoid collision with music. That was, plain and simple, bad design. That design bug is now fixed. One no longer needs to resort to tricking MuseScore into placing a header into an artificially enlarged margin just to avoid music. Simply set the margin the actual size you want the margin to be - the actual amount of white space you want to leave - and the header will automatically stay out of the margin and avoid collisions with the music. That's the way headers work in most other programs as well.

So, in short, now that the 3.6.2 bug is fixed, to get the layout you want, simply set the margin to what it actually should be - the actual amount of white space you want to leave - instead of an artificially large value to encompass the header.

Reply

• aug 11, 2023 - 14:45

Indeed, and there is actually a bug here worth fixing: the algorithm that computes the amount of space required for the header allocates (way) too much space if you use the old-style hack of applying a negative offset to force the header into the margin. But, the whole point of the new system is to no longer need that hack.

Probably when this was implemented for MU4, a migration strategy should have been implemented - reset the offset, decrease top margin size to compensate. I guess something similar could be considered for 3.7, but not sure how practical that is. It could make more sense to revert the change.

Reply

• aug 11, 2023 - 15:59

Reply to Marc:
Yes exactly that's what I am thinking about too. Thanks Marc.
Not every little or big change and difference in MS4 makes sense to be backported to 3.7. Such "not new" features (that exist before) should be carefully be analyzed first and proofed if it's not beeing a regression for 3.6-users who most likely understand 3.7 as a comatible update to 3.6 and not just as an other version of MS4.
Completly new features of MS4 can be backported (if they do not include a bug), but highest care should be taken in backporting existing features.

Reply

• aug 11, 2023 - 16:18

I don't think that there should any substantial layout changes between 3.6 and 3.7, they should remain 100% layout compatible, even if that means keeping some minor bugs. So my vote would be against making this change. I know that scores could be automatically adjusted from 3.6 to 3.7 but this itself would require programming and the possibility of bugs and would take time away from more useful developments.

Reply

Van még megválaszolatlan kérdése? Please log in first to post your question.