Proposal to refactor the beam object in part.measure.beams

[rpatters1]

I quite like the inclusion of an array of beams at the part.measure level. It elegantly solves a number of challenges, including

• where a beam starts and ends
• which events are in the beam
• cross-staff beams.

(The one cross-staff beaming situation that may not be covered is multi-percussion layouts where there is cross-staff beaming across the entire layout, but I leave that as an aside for now. I have also seen full orchestra layouts in contemporary styles that cross-staff chords and beams across the entire full orchestra score. That also is an aside.)

Why a refactor

I am proposing this refactor because to me the current beam object seems very prescriptive and has a lot of opportunity for error in how it is to be interpreted. My proposal is driven by the following observations.

• The number of beams/flags on a note is determined entirely by its note value. A 128th note inside a beam must have exactly 5 beams. If there is no adjacent 128th or smaller note value, it must have additional hooks so that the total number of beams equals 5.
• Any software that draws beams will already be handling this. All it needs from MNX is where the primary beam starts and ends, and which events are included in it. The nested structure is overkill and will almost certainly be ignored, because:
• There is a complex opportunity for mismatches between the nested beam structure, the hooks array (as currently specified), and the number of beams required by each note.

The proposal

Here is my proposal for a refactored beam object.

{
    "beams": [
        "events": [
            "aaaa",
            "bbbb",
            "cccc",
            "dddd",
            "eeee",
            "ffff"
        ],
        "breaks:" [
            {
                "event": "cccc",
                "beam": 2
            },
            {
                "event": "eeee",
                "beam": 3
            }
        ]
    ]
}

The events array would be exactly the same as it is now.

Instead of an inner array, there would be an array of breaks. These would specify secondary beam breaks. The beam number would be a number >= 2 specifying which beam to break (where 1 is the primary 8th beam, 2 is the 16th beam, etc.) Secondary beam breaks would only be required if the specified secondary beam would otherwise continue to the left and right of the specified event. Specifically, they would not be required in a situation like the two 16th notes in the Beams example.

Instead of the hooks array, I would propose that a hook object be added to the event object, since the event's note value is what determines the presence of a hook. However, whether hooks are moved to events or stay in beam, they should only be used when there is a desire to manually override the default hook direction, determined by consuming software. (See the 2nd bullet above. Any software that knows how to draw beams has to be able to draw hooks as well. And it has to have an algorithm to determine which direction the hooks should go without being told.)

Example refactor

Here is what a refactored beams array would look like in the secondary beam breaks example.

{
   "beams": [
      {
         "events": [
            "ev1",
            "ev2",
            "ev3",
            "ev4",
            "ev5",
            "ev6",
            "ev7",
            "ev8"
         ],
         "breaks" : [
            {
               "event": "ev5",
               "beam": 2
            }
         ]
      },
      {
         "events": [
            "ev9",
            "ev10",
            "ev11",
            "ev12",
            "ev13",
            "ev14",
            "ev15",
            "ev16"
         ],
         "breaks" : [
            {
               "event": "ev11",
               "beam": 3
            },
            {
               "event": "ev13",
               "beam": 2
            },
            {
               "event": "ev15",
               "beam": 3
            }
         ]
      }
   ]
}

And for the Beams example it is just a list of events in the beam:

{
   "beams": [
      {
         "events": [
            "ev9",
            "ev10",
            "ev11",
            "ev12",
            "ev13"
         ]
      },
      {
         "events": [
            "ev14",
            "ev15"
         ]
      }
   ]
}

The secondary beam of 2 16ths is implicit in their note values, and there is no need to specify it further.

(BTW: there is a typo in the sample file. The second beam in this example shows "ev15" as both the starting and ending event.)

Final thoughts

As you can see, this proposal produces much less verbose beam descriptions, yet it provides all the information that is needed by a consuming program to render the beam.

I proposed a numbering system of beams starting with 1 as the primary, but other schemes could be used instead. A starting value of 2 seems awkward in a computer program. We could number only the secondary beams and start with 1 as the 1st secondary beam (i.e., the 16th beam). We could use note value bases to specify the beams. I proposed the numbering scheme I did because it occurred to me there may be other situations where we need to refer to any beam, including the primary beam, and 1 as the primary seemed the most natural to me.

[mscuthbert]

Hi Robert -- thanks for this contribution. The co-chairs discussed this at our meeting today and we've raised enough concerns about this proposal that we are going to retain the current version unless there's a way to make this proposal address them.

For reference, we're mostly talking about the second measure of this example, where the notes/rests are ev9,10(rest),11(16th),12(16th),13:

How would pure-rendering (non-editing) software, such as Vexflow (or in the past, Finale Reader), know that when it encounters ev11 it needs to create a start beam for the 16th level and that when it gets to ev12 it needs to conclude the beam? Wouldn't software that uses mnx as a native file format need to recompute all beam information for the piece at every file open? And where would information about particular beams, such as their spacing from previous beams, thickness, color, etc., be stored?

It is for these use cases that we've decided to stick with the more complex current format. Thanks!

[rpatters1]

Hello. Thank you for taking the time to consider the proposal. I guess I don't understand the issue around measure 2 with the 16ths. Any software that can draw beams surely knows that 16th notes must have 2 beams. Thus, if there are 2 16ths in a row, and all the other notes in the beam are 8ths, they must have a 2nd beam on those 2 notes and only those 2 notes.

As for spacing, thickness, color, I could imagine adding those to the beam object (in arrays if need be.) I don't know enough about the requirements to suggest solutions. My personal preference would be to store as much of that into house styles as possible. House styles are a missing section of the current spec, in my opinion.

I would flip the question. Suppose a file in the current format specifies a list of events in a secondary beam that aren't 16ths or smaller? Does Vexflow have the intelligence to flag that as an error? If so, then it also has the intelligence to calculate the beams from my proposed format, obviating the need for any error checking. If it can't detect the error, how likely is it to be a reliable MNX importer? I don't know much about Finale Reader, but I would bet $5 that it had enough intelligence to draw beams from this proposed spec. (My first approximation guess would be that it used the same Enigma engine as Finale.)

I was expecting pushback on these two issues:

• rests under beams, and whether secondary beams should include them
• feathered beaming

I can see where these might take some wrangling to figure out solutions. But I think it is a mistake to allow the MNX spec to specify beaming that is in conflict with the note values, even if only in error.

[rpatters1]

To illustrate my point, consider the following example:

With the current spec, a simple music reader like Vexflow has to dive up to 4 recursion levels deep to figure out the beaming. Furthermore, if it is doing its due diligence, it has to track each level to make sure that any events listed in the next lower level are also listed the level above. And (again if doing due diligence) it still has to make sure that each note value has the correct number of beams for the note values.

With my proposal, it simply traverses the events in the beam exactly once to determine where each secondary beam starts (based on note value and beam breaks). Then it draws the beams. My proposal is much simpler and has much less room for errors.

Here is the current format for that beam (exported from Finale):

                    "beams": [
                        {
                            "events": [
                                "ev5",
                                "ev6",
                                "ev7",
                                "ev8",
                                "ev9",
                                "ev10",
                                "ev11",
                                "ev12",
                                "ev13",
                                "ev14",
                                "ev15",
                                "ev16",
                                "ev17",
                                "ev18"
                            ],
                            "inner": [
                                {
                                    "events": [
                                        "ev5",
                                        "ev6",
                                        "ev7",
                                        "ev8",
                                        "ev9",
                                        "ev10",
                                        "ev11",
                                        "ev12"
                                    ],
                                    "inner": [
                                        {
                                            "events": [
                                                "ev5",
                                                "ev6",
                                                "ev7",
                                                "ev8"
                                            ],
                                            "inner": [
                                                {
                                                    "events": [
                                                        "ev5",
                                                        "ev6",
                                                        "ev7",
                                                        "ev8"
                                                    ]
                                                }
                                            ]
                                        },
                                        {
                                            "events": [
                                                "ev9",
                                                "ev10",
                                                "ev11",
                                                "ev12"
                                            ],
                                            "inner": [
                                                {
                                                    "events": [
                                                        "ev9",
                                                        "ev10"
                                                    ]
                                                },
                                                {
                                                    "events": [
                                                        "ev11",
                                                        "ev12"
                                                    ]
                                                }
                                            ]
                                        }
                                    ]
                                },
                                {
                                    "events": [
                                        "ev13",
                                        "ev14",
                                        "ev15",
                                        "ev16",
                                        "ev17",
                                        "ev18"
                                    ],
                                    "inner": [
                                        {
                                            "events": [
                                                "ev13",
                                                "ev14",
                                                "ev15"
                                            ]
                                        },
                                        {
                                            "events": [
                                                "ev16",
                                                "ev17",
                                                "ev18"
                                            ]
                                        }
                                    ]
                                }
                            ]
                        }
                    ]

That just seems like a ridiculous amount of error-prone redundancy without any benefit. By comparison, here is how it would look under my proposal

                    "beams": [
                        {
                            "events": [
                                "ev5",
                                "ev6",
                                "ev7",
                                "ev8",
                                "ev9",
                                "ev10",
                                "ev11",
                                "ev12",
                                "ev13",
                                "ev14",
                                "ev15",
                                "ev16",
                                "ev17",
                                "ev18"
                            ],
                            "breaks": [
                                {
                                    "event": "ev9",
                                    "beam": 3
                                },
                                {
                                    "event": "ev11",
                                    "beam": 4
                                },
                                {
                                    "event": "ev13",
                                    "beam": 2
                                },
                                {
                                    "event": "ev16",
                                    "beam": 3
                                },
                            ]
                        }
                    ]

[rpatters1]

I just looked at this tutorial page for Vexflow. It is quite obvious that Vexflow knows that 8ths need 1 beam, 16ths need 2 beams, and 32nds need three beams, without having to be told where each one starts and stops in a hierarchy. My proposed refactor would translate directly into Vexflow, and the current design adds a lot of complexity that (if I were implementing the MNX import for Vexflow) I would probably just ignore.