Nightly build 32-bit?

• Jul 14, 2021 - 21:09

Hello,

because I can't program and the nightly build seems to be just 64-bit, would anyone be willing to create 32-bit version of nightly build of MuseScore 3?

Comments

• Jul 14, 2021 - 21:35

While I'm sure that would be possible, is there a reason you would want one? There have not been regular updates to the 3.x branches since the release of 3.6.2 - virtually all development work is going directly to MuseScore 4. So unless there is a specific bug that you know to have been fixed in the 3.x branch, there wouldn't really any point to using a nightly of MuseScore 3 at this time.

Reply

• Jul 23, 2021 - 15:39

Thank you very much for your answer.
There are several reasons why I'm requesting a 32-bit nightly build of version 3:
1. I wrote all my compositions (around 90 pieces) a few years ago in version 2. Because version 3 contains, in addition to improvements in program control and notation itself, new music fonts, and because the file format is no longer fully compatible with version 2, I rewrite my compositions in version 3.
2. I tried to install a 64-bit OS (Win10Pro) on both the desktop and the laptop. During not only the installation of the OS itself - especially the various necessary drivers, but also the programs and their use, there were still some problems, so I went back to the 32-bit version of the OS.
3. Although the file format in version 4 is probably the same as in version 3 - 1. due to the different look of the program, 2. because I'm as one says an old school man and 3. I don't think the ability to play (/ export to any sound format) exactly according to the expression symbols in the notation is so much improved, so there is not a good reason for me to switch to version 4.
These may not be strong enough reasons for you, but since the expected update 3.6.3 will most likely not come out, I'm looking for someone who would be willing to create a version 3 build with all the bugs fixed after the release of version 3.6.2.

Reply

• Jul 23, 2021 - 15:58

1 is not a reason, MuseScore 2, 32bit, does work on 32bit and 64bit Windows. The scores can be read by MuseScore 3, whether that is 32bit or 64bit is irrelevant.
3 is not a reason either. And the file fomat has just been changed yesterday, so is no longer identical to MuseScore 3, still whether that is 32bit or 64bit is irrelevant to reading scores.

The only good reason to use a 32bit MuseScore is if you're using a 32bit Windows. So the releases do get provided for that. Whether that'd still be the case for MuseScore 4 is yet to be determined though, any might depend on the Qt version being used at the time (Currently we're using Qt 5.15.2, but Qt 6.x doesn't seem to support 32bit Windows anymore).
The other supported Platforms, macOS and Linux are 64bit only.

Creating all these development builds is already using quite some resouces, that's why an additional 32bit development build for 32bit is not created, the number of potential users is pretty small too.

Reply

• Jul 23, 2021 - 23:45

Indeed, I did see that at the very end, but everything up until that point made no sense.

As for bugs fixed after 3.6.2, there are barely any, since the vast majority of development work in only happening on the master branch. And those fixes that have been made for the 3.x branch are largely untested, so unless there is one very specific bug that one is concerned about, simply building an "everything added since 3.6.2" is likely to produce something buggier than 3.6.2 itself due to the untested interactions in those changes.

So again, I'm missing anything resembling an actual reason for wanting such a build - a specific problem that would theoretically be fixed. The only one I can think of that might justify wanting an untested/unsupported post-3.6.2 build for would be the macOS / HO PaserJetPro / Leland incompatibility issue, but that doesn't seem to apply here.

Reply

• Jul 26, 2021 - 22:49

Not all those are actual bugs, and not all the PR's actually fix the bugs they are addressing - the PR's that got merged in 3.x post-3.6.2 did not really go through the normal review process due to the shift of all resources to master, and the merging stopped arbitrarily at some point, meaning there might be some groups of PR's that were designed to get merged together but didn.t, leaving the work half-finished and thus potentially broken. Also, many of those PR may well introduce other bugs since they were never tested, and they may create bad interactions where one particular PR is fine, so is another, but the two are inherently incompatible and together make things worse.

So, bottom line if the goal is to have the most stable version of MuseScore, then absolutely positively without the slightest shred of doubt, stick to the official release.

If on the other hand there is one specific bug you are concerned with getting a fix for, let us know which, and we can give our impression of whether a PR that purports to fix that specific bug could safely be added (by you or someone else willing to self-build) to 3.6.2 as a patch.

Reply

• Jul 27, 2021 - 19:51

For some of them, the development was done on master and merged there, in some cases without much testing because master was barely working, and they were applied to 3.x just as a matter of course as opposed to this being based on any serious analysis of the impact on 3.x. That also includes (or should I say, didn't include) much consideration of the risk / benefit for each merged PR.

I'm not saying they didn't get examined at all, just that the norms of how we might normally treat PR's to be merged between 3.6.2 and a hypothetical 3.6.3 - only the most critical, least risky fixes - were not really followed here.

Reply

• Jul 27, 2021 - 20:19

If a 3.6.3 is going to happen, than there will be more testing.
As long as none is planned, there's no motivation or benefit for anyone to do any thorough testing.

I just found a couple minor issues in my big bundle and fixed them.
Seems only some mtest failures, where the tests need to get adjusted, no code change needed, except possible for one commit, which I've reverted for now.

Reply

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