Unison clash failing on site; no, this is not a "site problem".

• Apr 7, 2020 - 13:48

Take a look at the minimal test case https://musescore.com/bsg/scores/6069325 .
This plays correctly in OS: macOS 10.15, Arch.: x86_64, MuseScore version (64-bit): 3.4.2.25137, revision: 148e43f .

As you can hear, it does not play correctly on the site; the whole note is clipped by the quarter note.

I thought this was fixed years ago. What is the site running? I tried that sample on Linux, 3.4.2 (AppImage), and it did not fail. What on earth is the site running that this still does not perform correctly? I don't know where the fault lies, but this is corrupting my carefully-prepared scores.

How can we find out where the problem is and get it fixed?

Comments

• Apr 7, 2020 - 14:15

Yes, indeed, but I thought that the site always ran the latest version a day or two after it was released. That has indeed been my experience when relying on new features, which is why it is something of a mystery.

For instance, I eagerly awaited the appearance of 3.3, with Campania, to see my cool Roman Numerals appear, and within days of 3.3 release, there it was. But unison collision cutoff was fixed a long time before that. So I cannot hypothesize what point in time the site's engine represents, and I don't know what build (or what platform). I hypothesize that there is some build of 3.4.2 they are using that fails in this way.

But even so, you are right that I should at least complain to the site, and I will.

Reply

• Apr 7, 2020 - 21:37

Reporting to the site was the right thing to do for sure. My understanding is that there is a special "backend" built especially for the site that generally is built from the same source as the current version of MuseScore but every so often some PR will be merged for the application and somehow get missed for the backend (or vice versa). So my guess is this was one such case.

Reply

• Apr 7, 2020 - 21:53

Oh, this is chaos (or, reproducing an internal diagnostic in the PDP-10 Lisp compiler (NCOMPLR), "KING OF CONFUSION"). This is a recipe for irretrievable dysfunction. Who is in charge of maintaining that bogon? How can this ever be fixed if it involves a PR dropped 2 years ago? It would be good if there were a way of DISABLING the fix in the application so behavior on the site was predictable.

Reply

• Apr 7, 2020 - 22:09

No, the code should simply match - which is to say the site should be fixed. It's actually not that big a deal to have multiple applications built from the same basic source,e it's also how the mobile apps are made. For the most part I think the process in place for merging PR's does result in things being synced, it's maybe happened two or three times in the past decade I can recall that things have gotten off for whatever reason. I suspect in this case it was a PR that was merged then reverted then another one partially replaced it or some weird sequence of actions that got in the way, not really sure, but anyhow, the system works fine in general, no big deal to just report the rare problems when they are discovered so they can be fixed.

Reply

• Apr 8, 2020 - 14:51

Here’s what I know (been pointed to this thread by BSG):

I fixed this in 2.x completely. However, because there was (and still is, oops) no UI to easily assign different voices within one stave or grand stave to different MIDI channels, @lasconic added code to implement restriking instead of keeping the note sounding. This has made it into the official releases, but I’ve been carrying a local patch reverting the restriking in the Debian experimental packages (not in the Debian packages users normally get, mind you). The restriking code received several bugfixes in the meantime (none were applicable to the keep-sounding code).

I vaguely recall that, when the patches got forward-ported to MuseScore 3 (then just master), one of the post-restriking bugfixes patches got lost. I informed people in IRC about it, but didn’t track what became of it, and can’t find it right now.

When I installed MuseScore 3 myself, with the revert-restriking patch, I noticed in the console messages (the keep-sounding code informs the user about collisions on stderr; something that is not really possible in the restriking patch) that, apparently, MuseScore 3.x at some point of x (probably > 0) does not render the entire score into MIDI at once any more; rather, it seems to render it in chunks. When asking about this on Telegram, the core developers (Anatoly IIRC) told me that this observation is correct, and to my question about the note collision state (which of course must be carried over) to not worry. (I’m not sure this is correct, but I haven’t yet found the time to check whether this will indeed work as necessary; a score MUST NOT be partitioned if a note is still sounding (using keep-sounding, not restriking, terminology for the ease of my mind), or the internal state of the collision tracker MUST be carried over to the next partition; I’m fairly sure the code will need changes, pessimistic/cynic developer that I am.)

So, perhaps either one of the patches is still lost (which would affect, IIRC, exports to MP3 from the command line… basically what the backend does), which you can test by using a collision-heavy score; in this case, all collisions will be broken… or the affected note you hear crosses one of the render partition boundaries and the reassuring I got from the core developers about not needing to worry about it was wrong.

This is all from back-of-my-mind, I’ve got to get back to work and not time to investigate it fully.

Reply

• Apr 8, 2020 - 15:36

OK, I can confirm this goes as far back as 3.2.3:

A 3.2.3 OS: Debian GNU/Linux sid, Arch.: x86_64, MuseScore version (64-bit): 3.2.3+dfsg1-4+b1 (Debian sid/amd64), MuseScore build number not set, revision: d2d863f with_out_ my revert-restriking patch exposes the following:

  • MP3 exported via command line (mscore3 -o x.mp3 x.mscz) broken
  • playback in the software OK
  • MP3 exported from the GUI broken

So, indeed, a fix from 2.3.2 got lost.

With the revert-restriking patch applied, this works, of course.

Reply

• Apr 8, 2020 - 15:46

That is a correct description of what I observed; it plays properly from the score, but not from the "Export to MP3" MP3, on my Mac, and it is clearly larger than, and not specific to, the .com backend. I'd appreciate trying it on Windows (download that score, export to MP3, and play).

While I don't fully understand @mirabilos' chronology, the issue is clear, and I will post it in the tracker.

Reply

• Apr 8, 2020 - 12:33

You forgot to say "minus some patches" as Marc pointed out. Who develops this version? Whose responsibility is it? Who can maintain this and merge the lost patches which are destroying unison collisions? Worse than the misbehavior is the fact that the release behaves differently, so scores cannot be fully debugged and tested before uploading. Is it my responsibility to try to merge the patches, build, and test this? Is there even a Mac build? How does one test it? I worked with @mirabilos to design this fix a long time ago; they are his patches. Maybe he has to do it? (I've written him).

Reply

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