End of Life plan for 3.x ?

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


Commenti

In risposta a by XiaoMigros

A poor analogy. It is quite reasonable, and fully expected, that MS4 scores will be incompatible with MS3.6.2 but I think that a lot of consideration should be made before making 3.7 scores deviate from full compatibility with 3.6.2 unless they are prevented from being uploaded to musescore.com.

Where does this end? The more that 3.7 diverges in compatibility with 3.6.2, the less attractive it becomes as an update. Maybe the severity of the bug merits this deviation, but maybe not.

In risposta a by yonah_ag

There is still a considerable number of users of MS3.6.2, not only because of security or privacy concerns related to Muse Hub but also because as yet it is far from allowing all the functionality of MS3.6.2 and it is more hardware demanding
I think there should be sort of a compatibility plugin so that a MS4 score could be opened with MS3.6.2 keeping at least most of its layout. The workaround is to export from MS4.2 to .musicxml or .mxl and open it from MS3.6.2, but the layout is ruined.
Another option would be that MS4.2 could also export to a MS3-compatible .mscz format

In risposta a by Jojo-Schmitz

I was referring to the last official version.
By the way, so far I couldn't succeed locating a downloadable version of 3.7. It's my fault, I know, but the links you have provided lead to directories with a structure I don't understand. I'm not a developer and I ignore even the most basic terminology regarding github. I find a lot of folders and files with unfamiliar extensions and I am completely at a loss with all that stuff. I would love to try MS3.7 if only I could locate and download it.

In risposta a by Jojo-Schmitz

Hello,

It seem to work perfect here.
With the latest windows build the header-foorter is fine also I suppose.

One small problem.
I have 14" laptop with 150% scaling in order to be able to read the letters.

Musescore has some problem taking into account that scaling.
I suppose it has to do with Qt (dorico had also that scaling problem in earlier versions)

I can fix it with a compatibility HDPI setting in windows for musescore.exe

Maybe there is a better solution for that.
Thank you and kind regards,

Allegato Dimensione
High DPI.png 117.43 KB

In risposta a by Jojo-Schmitz

The (mis)scaling problem at >=150% windows-screen-scaling (especially the much too big mixer sliders) occures in all versions MS3.6.2 to 3.7.0, 32-bit and 64-bit. The sliders go to just about half the scale, if switched from 150% to 149% or lower of windows-display-scaling.

In risposta a by Jojo-Schmitz

I would like to give some suggestions :
1 - Have a webpage for the 3.7 with a download link.
2 - Backport the double-click to enter edit mode feature.
3 - Improve zerbeus volume. Some instruments that are correctly leveled at Sforzando and at Sfizz get audible volume differences in Zerbeus, when switching from one dynamic layer to another or among different instruments at drumkits. Sfizz works much like Sforzando and if zerbeus did the same it would provide nice support for sfz.

In risposta a by Jojo-Schmitz

My 2'cents Proposal:

1) https://github.com/Jojo-Schmitz/MuseScore/ is a fork of Musescore/Musescore.
As a fork repository, contribution doesn't count towards your activity in your (or other contributors github profile), this could discourage contribution. By copying the repo into a fresh github repo the fork link is removed. The upside of this is that 3.x branch (which as of now is kind of esoteric since its upstream doesn't exist) will be the new 'main' branch.

2) New code/contributions is formatted as Musescore4, yes this will result in mixed formatting. I'm doing it currently and find no problems reading the old format, or mixed formatted code. It has the upside of easy seeing what is older and should be handled more gently (yes, git blames does that also).

In risposta a by larryz

1) I don't understand this. But even in the upstream preo only non-merge commits to master counted as contributions. I'M only workong on the 3.x branch in my repo, under the assumption that this won't change anymore upstream.
2) On my 3.x branch I'll maintain the 3.x style. That BTW is one of the problems of your album PRs, albeit the least ot them.

In risposta a by BanjoJake

Yes, that Ignore is needed (and it not an error but a warning) and yes, all styles are set to their defaults, that's a problem I still have to solve, would need to read in the style file from the Mu4 .mscz too. (and not only the style file, like without the code change)

Tempo notes are smaller in MS3.7

:

This is MS3.6.2

MS362.png

and here is exactly the same score, unchanged, in 3.7.0

MS370.png

As you can see, the tempo crotchet symbol is sized differently even though both are Edwin 12 pt.

Congratulations and thanks Jojo. Now the backward compatibility of MU3 openning MU4 files is working nicely. We can finally switch back and forth between the freedom of choice of 3.7 and the realism of Muse sounds in 4.x.

In risposta a by fernandoamartin

This might grow to a very interesting feature. Many thanks for that!
But at that very first implementation state some really important things go lost during import (eg crescendo lines, expression texts and so on or also some text styles like "Dynamics"). All other elements they do import (and are not auto-placed) unfortunately are not scaled by the "Format / Page Settings / Staff Space" factor during import, so they all will not lie at the initially defined correct positions in the score and must be moved and/or resized after importing (see https://github.com/Jojo-Schmitz/MuseScore/issues/165). This also includes element positions, distance spacers and many other defined distances (eg gap settings before and after frames or images).

We hope this could be corrected as soon as possible, so that interesting import functionality might get practical and useful in future time.

In risposta a by HeinzVo

I believe Mu4 import in my Mu3.7 is pretty decent now.

A Mu3 -> Mu4 -> Mu3 roundtrip still does loose a few things:

  • measure stretch (this is be design, Mu4 resets those explicitly and on purpose)
  • user offsets of ornaments
  • (none)play property of ornaments, fixed in 4.2
  • (in)visibility of ornaments
  • (none)autoplace setting of elements, fixed for ornaments in 4.2
  • font style and size of dynamics (at least the size is getting reset by Mu4 explicitly and on purpose, and Mu4 also used the Musical font for dynamics rather than the Musical Text font or any 'regular' text font, so this is beý design too)
  • tremolo offsets (this is be design, Mu4 resets those explicitly and on purpose)
  • stem lenght (this is be design, Mu4 resets those explicitly and on purpose)
  • directions of 'inner' ties (this is be design, Mu4 resets those explicitly and on purpose)

All these because they get lost on import of Mu3 scores in Mu4 already, so nothing I can do about those, other than reporting that as bug (for those cases that are not by design, see also cmd.cpp, resetDefaults(), lines 2463-2525), which has been done.

It also looses stuff that exists only in Mu4, like 2- and 4-measure repeats, straight flags, etc., nothing can get done about that other than backporting those features, which is way too big a task.
It also looses parts, so those need to get generated (and formatted) again, I might eventually be able to fix that. Or maybe not...

If you find more issue with this: just let me know, preferably via an issue in my fork.

In risposta a by fernandoamartin

Thank you for making this 3.7 fork.

I use MS3 because it is like a Swiss Knife for classroom and education.

  • Works well even on modest hardware.
  • Is available in different languages.
  • Installs in 5 minutes even without admin rights. (portable)
  • Can use midi keyboard for modest real time playing and demonstration with decent latency.
  • Possible to chose dedicated audio drivers. ASIO - WASAPI etc.
  • Has a very small mscz file size compared to for instance dorico files. (Easy and fast sharing via mail or other)
  • Works on all computers the same way. (no messing with scanning Vsti or installing GB libs)
  • Almost never has problems with audio. ( I installed it on 40 different student laptops this month )
  • Great, fast well documented feature set.
  • Easy and very flexible workflow.
  • etc.

I understand what MS3 and MS4 are missing compared to the big boys. (sibelius, dorico, finale, online apps)
MS4 is trying to fill that gap but at the cost of its biggest strength for my use.
Maybe MS4 will become again that swiss army knife but for now it is not.
So I'm glad 3.6 continues to live with this 3.7 fork.

Thanks.

In risposta a by Johan-v

Some of your reasons seem flawed:
Mu4 is available in different languages too, I believe it has the same set of audio drivers as Mu3, it works the same on all computers too, as long as you don't use MuseSound the file size is comparable to Mu3, Mu3 does have its share of audio problems too

Is there a way to use the new MuseSounds in 3.7.x for Linux? I'd like especially to be able to use the ensemble string sounds, instead of using one violin/viola/cello/bass to represent a whole section.

Thank you @Jojo-Schmidt for trying to reward loyal MS3 users who dont want to change! I was so happy to use MS4 till i found it it doesnt work with windows 7. So i figured i'll be with 3.6.2 till i die.
I was happy to see youre trying to bring in some of the features of 4 back into 3, and saw youll be including VST support, so with that i decided to start a useless GitHub acct just so i can have that one feature. (I also wanted a better piano roll editor, but I'll work with the clunky old one if I can just use my orchestral VSTi's.)
I have successfully followed the instructions you gave on the dedicated web page for Evolution, and it opens fine and creates a new score on my Windows 7 64-bit computer. I am unable however to load VSTi's. When I open the synthesizer menu I'm only seeing options to add sound font files. I went into preferences to see if there was a special folder path that needs to be set, but that wasn't there. Is there a special trick to be able to load the plug-in instruments?
And also where can I find a list of changes you've made to test your added features?

So how about for Musescore 3.8 Evolution - same as 3.7 but with the engraving improvements of 4.* (but not the interface or musesounds of 4.*).

I have been running 3.6x for ages (MacOS) and was just trying to install 3.7, followed instructions on the site. I downloaded the most recent version, it seemed to act like a normal .dmg file, but after installing it, the computer says that the application file is damaged and should be moved to the trash. I am not a computer expert, just a user, and I am confused... what should I be doing?

In risposta a by ayermish

@ayermish

There are challenges when installing and running on a Mac.

First, the application is not digitally ''signed" so you have to convince the Mac that you really want to run it. Here's a link to a discussion that includes installation instructions.

Secondly, somewhere after ** macOS version MuseScore 3.7.0.4524440406, revision: f3d36a3** MuseScore 3.7 no longer sees any audio devices ... meaning it can't playback any sound.

You can get the version I mentioned, but:

• Surely there's a later version that still has functioning audio, but I don't know what that is.
• Hopefully development will solve the audio problem so those using MS3.7 can use the latest release

scorster

Hai ancora una domanda senza risposta? Effettua l'accesso per prima cosa per porre la tua domanda.