Tuplet numbers not always put on the correct side of beamings if <stem> not defined

[fablau]

Hello Simon and friends.

Here is another issue that should be tackled, and it is about tuplets.

Look at this example below, which includes the <stem> directive to tell the viewer how to orientate the stems (either "up" or "down"):

As you can see, the tuplet numbers are located on the correct side of the group beaming.

Now, look at the same example without the <stem> directive, which should leave the rendering decision of all stem orientations to the OSMD engine:

As you can see, most of the tuplet numbers are located on the wrong side of the beaming despite all stems are correctly automatically oriented. Is that something that can be fixed?

Eager to know your thoughts about it.

Thanks!

[sschmidTU]

You've added the same image twice ;)
also, can you share the MusicXML file? (zip or rename to .txt)

[fablau]

The two images are different, look at the tuplet numbers ;)

Here are the XML files, sorry, I forgot about them.

Archive.zip

[sschmidTU]

Oh, right, the numbers, sorry, for some reason I thought this was about the beams.
Thanks the for sample. Will take a look. Probably the numbers should be on the side of the beam always (if not otherwise given in XML).

[fablau]

Yes, exactly. They should always be on the beaming side if automatically positioned. Thank you Simon!

[sschmidTU]

Elaine Gould's Behind Bars (the reference on music engraving) also says the tuplet number should usually, but not always be on the side of the stem (pp. 197-198):

Though all else being equal the preference is always above, e.g. if there are other potential conflicts with a below placement such as many ledger lines or slurs used.

[fablau]

Nice reference! I'd add that that's absolutely true if you have no beamings and, ideally, a bracket. But if you don't have a bracket and have beamings, the number should always be on the beaming side ;)

[fablau]

Also, is there a way to tell OSMD to put the tuplet numbers nearer to the beamings when you have this kind of situation (look mostly at the last bar):

The distance between the group and the tuplet number is extremely high. Note: the above example includes the <stem> directive... and here is the same example without the <stem> directive:

Which looks better from a "tuplet number distance" stand point, but those numbers should be on the beaming side.

I am attaching the XML files of those examples as well.

Archive2.zip

[fablau]

@sschmidTU any thoughts on my last post above? Thanks again.

[sschmidTU]

No, there is no way to do that currently. Vexflow does part of the y-placement.

[fablau]

Ok, I see... but what about adjusting the side of the tuplet number, as I have explained? Is that something that can be fixed in OSMD?

[sschmidTU]

If you mean the first comment / issue opening comment, of course it's possible.

[fablau]

Sounds good. Is that something that can be fixed soon/easily?

Also, I am wondering if the second issue that you mentioned being a problem of Vexflow could have been fixed in the latest versions of it? Just wondering... otherwise I'll open an issue over there to have it fixed (or I can see if I can contribute to fix it).

Thanks!

[sschmidTU]

It should be relatively easy, but you only see when you try it.
Second issue I don't know, but I doubt it's fixed at Vexflow.

[fablau]

Thanks Simon. I just need to know if the first problem (tuplet's number orientation) is something that can be fixed relatively soon (3-4 weeks?) from your team, or if I need to tackle the code myself and do a pull request in case I understand what to do to fix it. The code is very complex, and I might spend entire days to figure out what section is taking care of that.

Thanks again ;)

[fablau]

@sschmidTU please, look at this discussion on the Vexflow GitHub issues section:

0xfe/vexflow#1594

What version of Vexflow is OSMD using? Just wondering... thanks.

[fablau]

Simon, by looking at OSMD source code it looks like it is still based on Vexflow 1.2.93. Can you confirm? If so, I guess you haven't updated it because of compatibility issues... maybe I can help with that in some way?

[sschmidTU]

Yes, it's 1.2.93, as you can see in the package.json.
Vexflow 3+ has layout issues. #1139

[sschmidTU]

We do apply a VexFlowPatch with lots of improvements, see src/VexFlowPatch/readme

[fablau]

I see Simon... I'll review everything and see if we can add a patch or something to handle that sort of tuplet display correctly.

In the meantime, could you please confirm if you or someone on your team can tackle my first issue posted above within the next 3-4 weeks? I am talking about the orientation of the tuplet's numbers to be located on the beaming side when a bracket is not present. I plan to release a new musicXML viewer based on your technology on our website, and it'd be nice to have that issue fixed before its launch. Otherwise, I'll look into it myself.

Thanks again!

[sschmidTU]

It's Sunday. You'll get an answer eventually.

[fablau]

Of course, and sounds good. ;) Happy Sunday!

[fablau]

While I was waiting for someone to answer my question above, I looked at the code, and I found that the tuplets are handled by this function inside the tuplet.js code inside VexFlowPatch/src/:

setTupletLocation(location) { if (!location) { location = Tuplet.LOCATION_TOP; } else if (location !== Tuplet.LOCATION_TOP && location !== Tuplet.LOCATION_BOTTOM) { throw new Vex.RERR('BadArgument', 'Invalid tuplet location: ' + location); } this.location = location; return this; }

The fact is, it looks like that function is never called! Any ideas on that? I tried with the attached XML file.

tripletsTestOSMDTnostems.musicxml.zip

[fablau]

Can anyone help me here? I think I could fix the patch for tuplets myself and maybe submit a pull request, but I need to know how to "apply" those changes to Vexflow. Do I need to compile those patches aside? I have no idea how to do it. Any changes applied to those JS files are not shown if I run the debugging with "npm start" or if I do a built for distribution with "npm run build"

I am eager to learn more about all this. Thanks.

[sschmidTU]

You need to run npm run prebuildVexflow to make the changes in VexFlowPatch take effect in npm start. This is by the way included in npm run build (as part of prebuild).

[sschmidTU]

By the way, this is also mentioned in the readme.txt in the VexFlowPatch folder, where you can also see a list of changes for each vexflow file.
(which should also be expanded for tuplet.js in case of further fixes)

[fablau]

Thank you Simon! I read the "readme.txt" but it wasn't clear how to do it. Your explanation above is perfect ;)

Thanks again.