I'm tired of Musescore 3.x disrupting smooth-running functions.

• Jul 3, 2019 - 13:59

Some patches (bug-fixes) disrupts another functions that works correctly.

The quality implementation is very low (since 3.x):
The person who makes the patch (bug-fix) sends a request and it adds with a simple review.
It seems that neither the person who made the patch (bug-fix) nor the person who accepts does not control in detail which areas of the software affect this change.

Suggestion:

Please pay more attention to the patch (bug-fix) you have written or changed.
Please pay more attention to the patch (bug-fix) you have reviewed and approved.

The areas affected by these patches make the software useless. And then it's harder to fix.
If each fix corrupts something else, the software goes away, and as a result we only have bugs.

Would you like to get a version like this:
'Complete bugged and much more faulty version of "Fuse-pop Score v4". It won't even started!'

This is the end of the subject.
Below is the answer to the question "what are you talking about and give a few examples about it" and it is not important for the subject.

Some examples (not all); These are very important to me:
1. Lost plug-ins, (or plug-ins that are listed many times after patching)
2. Save the soundfont list to the document each time without the user commanding (a simple save cannot be corrected),
3. Problems in user-defined styles and limitation of the number of styles.
4. Changing colors without the user's opinion (in many cases the user's opinion is not asked),
5. Self-changing patches in the mixer. (side effects of the expression patch system and 2. item in the list).
^ (Those listed above are functions that previously worked properly.)

and more ... https://musescore.org/en/project/issues/musescore?text=&tags=&status=10…

PS: Although Musescore's first priority is writing notes (which we can also do with pencil and paper), both composers, editors and transcripts want to hear the notes they write (we can't do this with pencil and paper).

Comments

• Jul 3, 2019 - 14:06

We need an issue in the tracker for each and every bug you find. Unless it is in the tracker already, like the 1st one about plugins (which got emergency fixed in 3.2.2, and really fixed just today in the development builds).
The 2nd one is known already, a first fix seems to not have been sufficient.
The 3rd is by desisn, not a bug.
The 4th is unknown I believe
The 5th might indeed relate to the (known) 2nd, but I'm not sure about that

We need you (plural) to test development builds and report issues found there!

You're not forced to upgrade immediatelly as soon as a new version gets released...

Reply

• Jul 3, 2019 - 14:24

The main (top) part of the message is more important to me.
Because I want this great software to be much better.
The problems I have listed are examples (I use 2.3.2 for all my important work and I have 3.x for testing purposes).
Thank you very much for reading, paying attention and answering.

Reply

• Jul 3, 2019 - 14:40

Regarding the main point:

As someone who has been contributing to MuseScore development for quite a few years now, I don't think anything has changed here. at our end Those of us who write the code do our very best to test. Those who review it before merging do the same. But it's impossible to think of everything, and sometimes regressions are indeed introduced. This has been true since day one and will continue to be true. We all do our very best to be as throrough as possible, but we're human.

What would help is if those for whom the quality of the software is a concern would actively use current builds (the current release for sure, but ideally more than a few people would be using nightly builds on a regular basis) to help us test in real world usage. Every minute people spend continuing to use 2.3.2 is a minute that could have been spent actually helping improve the software.

Reply

• Jul 3, 2019 - 18:21

Of course, all developers are doing their best.
Thank you for that.

But in the real world (and in business) results are more important than reasons.

And what should be done to get good results:
For example, automated tests can be developed.
A cross-control system may be introduced by at least three developers prior to merging the PR.
In addition, five or ten volunteer users can test this PR (eg: in a temporary pre-nightly version?).
And other things I didn't think about.

Reply

• Jul 3, 2019 - 18:37

Automated tests are in place, but can't cover everything.

Resources are limited, there are quite a lot code contributors, but only that merge those.

There are most probably more than five or ten volunteers to test nightlies, that apparently isn't enough, a much larger test coverage is needed. The changed that led to plugins not working had nothing to do with plugins, at least at first glance, so nobody explicilty tested those.

Getting things fixed quickly is far more important, and just 2 days between 3.2.1 and 3.2.2 and 3 days between 3.2 and 3.2.1 is proving that this does in fact happen.

MuseScore is free and OpenSource.
Free as in free speach and also free as in free beer, but everything in life comes at a cost. The above testing is one.
An OpenSource mantra is: release early, release often. MuseScore is doing this, since at least version 3, I think even since 2.2.

Reply

• Jul 3, 2019 - 18:40

We have hundreds of automated tests, with more constantly being added, and they catch a lot but can't cover everything.

I don't see a need for a pre-nightly if we had more people actually using the nightly builds, and we always waited a few days after the last change before a release to give time to test that last nightly. In theory we do that, but a few cases for various reasons it didn't work out that way.

Reply

• Jul 7, 2019 - 22:04

> but ideally more than a few people would be using nightly builds on a regular basis

PMJI...

Where are those published on the Web?

As a new C++ contributor I think it would be really great to be able to spin a PR's build into a test install so the issue fix can be checked by the submitter without them have to build the program. It seems a lot to ask of a bug submitter.

For example, I've been adding a few items to the PluginAPI and I'm faced with getting a, possibly non-programmer type, to try the change. For them they have to wait for a next release to really exercise the fix. That may be too late.

I think a method of creating throw-away installs for PR's would be very helpful to developers and tester's alike. It would make that process more iterative as well.

-Dale

Reply

• Jul 7, 2019 - 23:27

Thanks! I see them now.

I assume that's 'master' so a PR needs to be absorbed.

Perhaps some build/github wizard type person could figure it out.

A magic button in the github PR that, when pressed by those so appointed, can produce a particular platform install. When I push up new code the automatic sanity builds are triggered. I'm not sure how far those builds get before before they're considered acceptable. With some luck there might be an install package just hanging around just waiting to be plucked.

-Dale

Reply

• Jul 8, 2019 - 02:49

I just tried this out and it works pretty well.

I ran my test plugin and score against it and it worked as expected. Thanks for sharing this nugget!

While it's not a "Magic Button" it's great to have!

One PR I have pending is for a Mac user so this won't help for him but it's really nice to know for the Windows folks.

Thanks!

-Dale

Reply

• Jul 9, 2019 - 22:46

So you know, if you want more people to test a certain project, you can post a link in the technology preview and explain what you want tested and request feedback, you may or may not get any. There are a few of us non-programmers who hang out on telegram, if you add a link there, in a PR or in technology preview, I've been know to test the build and give feedback. I mostly write for classical ensembles, so I didn't test the guitar fingering mode Marc introduced a while back, but I did extensive testing of the continuous view improvements a few releases back.

Reply

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