Tuplets 3 and 6 are not yet annotated

[hbitteur]

Tuplets symbols recognition is mandatory because it impacts measure correctness

[lasconic]

I just created a MuseScore label, so we can list all MuseScore issues MuseScore
Please tag other issues with this label. Thanks!

[hbitteur]

Thanks, I will try to use it immediately /Hervé

…

On 25/09/2017 18:38, Nicolas Froment wrote: I just created a MuseScore label, so we can list all MuseScore issues https://github.com/Audiveris/omr-dataset-tools/labels/MuseScore — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVCDAmfpOSM0vWSeP9kG0EyWW1bfpADPks5sl9cKgaJpZM4Pi_22>.

-- Hervé Bitteur Audiveris OMR www.audiveris.com <http://www.audiveris.com>

--- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus

[lasconic]

MuseScore supports several notation for tuplets. How are we supposed to export the 4 following tuplets?

[hbitteur]

I confess I had never seen this "3:2" notation before. Is it something popular enough to be considered?

From Audiveris point of view, only "3" or "6" notations are currently supported. The rectangular "brackets" (upper left corner of the example) are not yet recognized, but I know we will have to do so because they are rather frequent. Moreover, they sometimes get upfront mistaken for character strings like "+-3-+", so the user has to manually perform: 1/ removal of the wrong text, 2/ addition of proper tuplet sign.

Now, which symbols should we use for such annotation? Perhaps a compound like : left-bracket, tuplet, right-bracket?

What do we have in SMuFL description that relates to this? Here is what I just read:
In tuplets SMuFL says that "Scoring applications should use primitives to draw tuplet brackets."
In beamed groups of notes we have textTupletBracketStartShortStem and textTupletBracketEndShortStem (and also versions for long stems).

So, what about coining symbols like tupletBracketStart and tupletBracketEnd for instance? Using nested symbols, the compound could be described as follows:

   <Symbol ... shape="bracketedTuplet3">
        <Bounds .../>
        <Symbol ... shape="tupletBracketStart">
            <Bounds .../>
        </Symbol>
        <Symbol ... shape="tuplet3">
            <Bounds .../>
        </Symbol>
        <Symbol ... shape="tupletBracketEnd">
            <Bounds .../>
        </Symbol>
    </Symbol>

I have coined the "bracketedTuplet3" symbol name just for the sake of the compound approach. If we don't want to use any compound, we can stick to the sequence of 3 symbols (tupletBracketStart, tuplet3 or tuplet6, tupletBracketEnd).

Just a proposal.

[lasconic]

MuseScore does support more than just "tuplet3" and "tuplet6" but if audiveris can just cope with those. Then let's ignore any tuplet but 3 and 6 (so we ignore ratios too)

Does the compound have any value for you @hbitteur ? If yes, does it have a value as "bracketedTuplet3" or just "bracketedTuplet" (and then it can include tuplet3 or tuplet6)?

[hbitteur]

@lasconic This is just a proposal so that we can move forward with these bracketed entities. Like I said, such construction is not yet supported by Audiveris, nor by the OMR Dataset project.

Regarding the compound value, this is meant to make dataset content as future-proof as possible.

Current Audiveris works bottom up: it tries to build ensembles from members.
But another OMR, or perhaps next Audiveris version, may work the other way around, and recognize the ensembles directly (I expect such possibility from the coming patch classifier).

In the former case, interest is on members: tupletBracketStart, tuplet3, tupletBracketEnd.
In the latter case, interest is on compound: bracketedTuplet3, and then it is important that the compound be fully specified (bracketedTuplet3 is OK but a bracketTuplet would not, since it would require the program to decompose the symbol into smaller sub-symbols just to detect a tuplet3 or a tuplet6, which would defeat the compound-based approach.

Granted, the proposed compound notation is indeed redundant because it aims at being usable for both member-first programs and compound-first programs.

[nasehim7]

So what is our take on the Tuplets now?
What should be our final design for the XML?
This :
<Symbol interline="20" shape="tuplet6"> <Bounds x="184.297" y="195.832" w="9.761" h="13.780"/> </Symbol>
or we want something compound? :)

[lasconic]

I would for something compound for triplet and sextuplet and not export the other tuplets for now. So similar to #22 (comment)

[hbitteur]

I would say: go for the nesting approach whenever you can:

• For an isolated 3 tuplet, it's a single symbol
• For a tuplet 3 surrounded by brackets, use nesting: The outer element would be the compound (with a shape like bracketedTuplet6), and the three inner elements would be the member symbols (tupletBracketStart, tuplet3, tupletBracketEnd) in this order.

Similar approach for tuplet 6, with or without brackets.

No need to cover over kinds of tuplets for the time being.

[nasehim7]

just to clear things
This one is a simple symbol for Tuplets

and This one is bracketed for which we need to do the nesting

[hbitteur]

Perfect.

[nasehim7]

Are these going to be the bounds we are interested in for bracketed tuplets? I think the current implementation is able to get the whole symbol (i.e. Red box) as It uses the same function for each element. Update: I have made the layout change for the compound description of Tuplets in my local repo and I'm able to get them exported same as #22 (comment). Working on getting the correct bounds.

[lasconic]

The blue ones, indeed. The one around the 3 too. But the large red one no, we want one around the other three ones.

[nasehim7]

This? :)

[lasconic]

No. Do not consider the rests (the 7 shape symbols) we don't care about them for this problem. We need the green one

<Symbol ... shape="bracketedTuplet3"> <!-- The green one -->
        <Bounds .../>
        <Symbol ... shape="tupletBracketStart">  <!-- The first blue -->
            <Bounds .../>
        </Symbol>
        <Symbol ... shape="tuplet3"> <!-- The 3 -->
            <Bounds .../>
        </Symbol>
        <Symbol ... shape="tupletBracketEnd"> <!-- The second blue -->
            <Bounds .../>
        </Symbol>
    </Symbol>

[nasehim7]

Okay, I get it @lasconic Now it's more clear. :)

[nasehim7]

I have completed doing the Tuplet Implementation as discussed here. I have tested it and for reference, the below snippet is right from one of the XML. Hope it is what we are looking for. :)

<Symbol interline="20" shape="bracketedTuplet3">
    <Bounds x="410.927" y="207.365" w="86.188" h="16.828"/>
    <Symbol interline="20" shape="tupletBracketStart">
      <Bounds x="410.927" y="194.865" w="33.585" h="10.000"/>
      </Symbol>
    <Symbol interline="20" shape="tuplet3">
      <Bounds x="449.512" y="207.365" w="9.019" h="13.656"/>
      </Symbol>
    <Symbol interline="20" shape="tupletBracketEnd">
      <Bounds x="463.531" y="194.865" w="33.585" h="10.000"/>
      </Symbol>
    </Symbol>

[nasehim7]

New edit done regarding the tuplets. For reference, below is the control image for tuplet

For right bracket and outer element, I think width needs to be 1 unit more. What do you guys think on this? @lasconic @hbitteur :)

[lasconic]

Hard to tell, I would say it's ok for now

[lasconic]

It looks good but after second though, what about exporting all tuplets MuseScore is aware and have audiveris deals with 3 and 6 only ? Same for timesig #28

[nasehim7]

We are into getting the first two kinds of tuplets, the simple ones, or is it that we want all 4 kinds ready? :)

[hbitteur]

@nasehim7 if you can export all the 4 kinds, simply do it.

Current Audiveris will digest the first 2 ones on the left (simple ones, with and without brackets) and probably ignore the last 2 ones on the right (complex ones; 3:2). But this applies for "current" Audiveris only. Another program (including another version of Audiveris) may be able to digest the complex tuplets.

[nasehim7]

@lasconic @hbitteur I think It will be good if we do it in two phases - we start it with somewhat like firstly get all kinds of the first two's, then in the next edit get all kinds of right ones as I think you guys would require nesting in that as to get "3:2" as a whole and "3" and "2" individually too.

[hbitteur]

Good idea

[lasconic]

I agree. Don't bother with nesting for 3:2 for now.

[nasehim7]

@lasconic how can we generate "3:2" bracketed tuplet in MuseScore?

[lasconic]

Create a triplet, select it and in the inspector on the right side, choose ratio. Ask on IRC or forum if you need more guidance.

[nasehim7]

Good news, finally done with implementing tuplets. All four tuplet types with their zero slant, up slant and down slant, are working. :)

Kudos to us :D