Why "a tempo" gets displayed as a system text? And other text placement issues...

[fablau]

Hello everyone.

I have just started implementing OSMD and I am testing it with some MusicXML files, and I see that OSMD incorrectly displays some staff-related text as system text, besides placing some text in the wrong position. It looks like that if the text contains "a tempo" OSMD interprets it as a "system" text and displays it as such.

Take this example:

https://www.virtualsheetmusic.com/test/osmd/TempoTest.html

The real system text is "Andante" defined inside the MusicXML file as follows, inside the first part section:

<direction placement='above' directive='yes' system='only-top'>
  <direction-type>
	  <words font-weight='bold' font-size='17.05'>Andante</words>
  </direction-type>
</direction>

Whereas "a tempo" is defined as regular text belonging to both parts independently. In fact, inside the MusicXML file, here is how the first "a tempo" is defined for the first part:

<direction placement='above'>
  <direction-type>
	  <words default-y='26' relative-x='-6' font-size='11.94'>a tempo</words>
  </direction-type>
  <voice>1</voice>
</direction>

And here is how's defined the second part:

<direction placement='above'>
  <direction-type>
	  <words default-y='11' relative-x='-6' font-size='11.94'>a tempo</words>
  </direction-type>
  <voice>1</voice>
  <staff>1</staff>
</direction>

And yet, OSMD displays it as if it was a system text. Try to hide either the violin or piano part, and you'll see that text is always displayed so that it is duplicated.

That's not correct. That text should be treated as regular text belonging to its own part.

What I say is confirmed by how OSMD is treating the other text, "rall..." which is defined inside the MusicXML file in the same exact way but is not displayed as a system text.

But another error appears here: even though the first "rall..." is assigned correctly to the first part, it is shown in the first bar instead of the second bar.

Any ideas on these issues? Am I missing something?

Here is the source MusicXML file in case you want to inspect it:

https://www.virtualsheetmusic.com/test/osmd/TempoTest.xml

I'll be waiting for your thoughts. Thanks.

[matt-uib]

This was done on purpose for tempo instructions, which to our understanding only make sense as system text, as all parts of a piece have to follow the same tempo. Reason for this was, that some musicXML authors do mistakes when using text instructions in a piece. E.g. adding a tempo instruction only at one staff - if the staff is set to invisible, the expression gets lost completely...
If you know of a certain use case, where it logically is required to have different tempo instructions for different parts, then it might make sense to solve this differently.
Regarding "rall." you are right - to be consistent that should be treated the same way actually. So either all "rall.", "rit.", "a tempo" are treated as system text or as staff text.

[fablau]

Thank you Matt for replying.

I don't think makes much sense to "assume" that certain texts are "system" texts while other aren't just based on the text content. I think OSMD should stick to the MusicXML definition. It's up to the MusicXML file creator to decide what's a system text and what's not. That's usually the way all systems treat definitions inside XML files.

In my specific case, I am working on using your system to display thousands of files from the Virtual Sheet Music catalog, and many of those present the same issue. The typical case is when the "a tempo" text has been typed by the engraver as a staff text instead of a system text in order to be displayed in both instrument staves (that may be considered a wrong approach, but a pretty common practice in the engraving of classical music).

What are your thoughts on that?

Thanks again.

[fablau]

Just to put it in perspective, here are three screenshots of the same file I mentioned above, which shows the problem with the OSMD system compared to other MusicXML readers, such as NoteFlight or MuseScore:

NoteFlight:

MuseScore:

OSMD:

Again, I strongly think OSMD should stick to the MusicXML protocol in order to have consistent results across platforms.

I'll be waiting for your thoughts.

Thank you!

[fablau]

Any more thoughts on all this and any chances to change this behavior?

[sschmidTU]

We can at least add a duplicate check. But the rest will at least not be high priority, because as matt-uib said, this potentially causes problems with inaccurately exported or written MusicXML files. And unfortunately a lot of MusicXML exporters aren't great and engravers aren't careful.
If you want to add an option/EngravingRule to not interpret these as system text in a pull request, we can definitely merge that.

[fablau]

Thank you for your reply. Yes, if we could have at least the option to avoid that, that'd be great! Thank you!

[sschmidTU]

I did not say I would make the pull request, I basically requested you to make a pull request ;)

[fablau]

Of course, I'll do that. Thanks!