First bar <words> inside <direction> not left aligned?

[fablau]

Hello everyone,
I keep working on testing OMSD, and here is another problem with the displayed text, in this case, the "words" element inside the "direction" element of the source MusicXML file.

Have a look at the screenshot below; it shows the first "Allegro" positioned in the center of the first bar, whereas it should be positioned at the far left of the first bar, exactly like the second Allegro, which is correctly positioned at the far left of the second bar.

Here is the MusicXML code of those two "Allegros" (I have truncated the code after the second "Allegro"):

<part id='P1'>
	<measure number='1'>
		<print>
			<system-layout>
				<system-margins>
					<left-margin>317.5</left-margin>
					<right-margin>0</right-margin>
				</system-margins>
				<top-system-distance>161.875</top-system-distance>
			</system-layout>
		</print>
		<attributes>
			<divisions>768</divisions>
			<key>
				<fifths>0</fifths>
				<mode>major</mode>
			</key>
			<time symbol='cut'>
				<beats>2</beats>
				<beat-type>2</beat-type>
			</time>
			<clef>
				<sign>G</sign>
				<line>2</line>
			</clef>
			<transpose>
				<diatonic>-4</diatonic>
				<chromatic>-7</chromatic>
			</transpose>
		</attributes>
		<direction placement='above' directive='yes' system='only-top'>
			<direction-type>
				<words font-weight='bold' font-size='8.56'>Allegro</words>
			
			</direction-type>
		</direction>
		<note>
			<rest measure='yes'/>
			<duration>3072</duration>
			<voice>1</voice>
		</note>
	
	</measure>
	<!--=========================================================-->
	<measure number='2'>
		<print new-system='no'/>
		<direction placement='above' directive='yes' system='only-top'>
			<direction-type>
				<words font-weight='bold' font-size='8.56'>Allegro</words>
			
			</direction-type>
		</direction>
		[....]

Is that something that can be adjusted via engraving rules ( I don't think so because I didn't find anything related to that, but I am asking anyway...) or via some other high-level parameter, or do we need to tackle the source code of OMSD to fix it? I spent a few hours trying to figure out how to fix it in the code, but I am wondering if this issue may be caused by VexFlow directly.

Any thoughts are very welcome. Thanks in advance.

[ammatwain]

Hi Fabrizio.
A temporary trick could be to place the time indication on the first pause of the invisible second voice composed only of pauses.

[fablau]

Oh, I see now... thanks for trick, but the OSMD system should handle that correctly.

After further analysis, it looks like the system seems completely ignores the "directive" flag for that first "Allegro" which should align it to the far left, exactly like the time signature as defined in the MusicXML documentation:

https://www.w3.org/2021/06/musicxml40/musicxml-reference/elements/direction/

By looking at the OSMD source code, I see no handling of that directive at all. Can you guys confirm that? If so, I could tackle the code and push a pull request.

Thanks again.

[ammatwain]

I'm sorry, I'm unable to confirm that for you right now. I'm just a user myself who recently started exploring this library.

[fablau]

Sure, no problem, I hope someone from the OSMD team can answer me.

Thanks!

[sschmidTU]

Yes, it would be nice to honor the directive attribute.
However, speaking as a musician, this is a minor graphical change that does not change the meaning or understandability. It's clear that the first tempo in the piece starts at the first note of the piece. It can also reduce collisions with other notation elements like a metronome number, which a change might cause.

[fablau]

Thank you Simon for giving your perspective and I agree with you that for a musician, that doesn't make much difference... but from a typographical point of view, that makes a big difference and it is considered a "typographical error." That's what makes a great music edition look like compared to a crappy music edition (and I am speaking as a musician, composer, and publisher).

I strongly think OSMD should follow MusicXML directives as closely as possible, aiming for graphical perfection (in the long turn, of course). Otherwise, it'll always be of lower quality compared to other music notation/rendering systems and can be just used for short pieces, simple songs, and such.

Collisions should be handled in a dynamic way. I am aware that's something more difficult to implement than getting away by keeping elements distant from each other. But that's clearly not a long-term solution.

Elements can be placed arbitrarily on the score, but the renderer should always follow the protocol directions. You can have a metronome indication "before" the tempo indication, and vice-versa... in which case, how do you handle the situation? You can have music with tempo change right in the middle of the bar... so, how would you handle that?

Of course, if you deal with just simple songs and tablature, you'll probably never encounter those kinds of situations. But if you want to make OSMD a universal music rendering system that is able to render any kind of composition based on Western notation, I strongly think we should think about all this and even more. I have spotted other important issues to tackle, such as:

1. Lack of correct time signature or first-note horizontal alignment when transposing instruments are displayed, with subsequent last note often going over the barline.
2. Repetition of tempo indications as I explained already in another thread.

If you think OSMD would be worth handling the "directive" attribute correctly, I'll be happy to look into the code and see if I can modify it in some way to allow that. Otherwise, I'll just work on my own.

Thanks for listening!

[sschmidTU]

I did say "it would be nice to honor the directive attribute". If a PR solves it (someone provides a solution), we'll happily merge it. If someone provides even hints for a solution or discussion, we'll investigate it. But unfortunately, we have a large project with many issues that want to be solved, I can personally only solve one at a time (though I'm not and shouldn't be the only contributor), and any of them could be done first. So I have to choose. What's more important, a tempo direction slightly more to the right (but not colliding or causing misunderstanding), or, for example, the wrong accidentals being used in some cases when using transposition (issue 1345)?
This is not to say that this issue will be put to the bottom to the list, I hope I can take a look at it myself some time on the side, but as I said, we do have to set at least a certain tendency of priorities, everything else would be irresponsible project management.
But as I said, if you would be willing to look into the code and try for a solution, we'd highly appreciate it! And we would help you if you have any questions or starting points for the coding part.

[fablau]

Thanks Simon for clarifying, I perfectly understand.

I'll try to figure that out myself, and of course, if I have any questions I'll ask you. Thanks for the offer!

I'll keep you posted ;)