Exact meaning and usage of useBeams

[rpatters1]

As I understand it, the useBeams flags in mnx.supports allows exporters to omit beams and then the consuming software uses whatever beam algorithm it has to beam the notes. However, the spec does not prohibit the inclusion of beams anyway. My question is 2-fold.

1. Are we to infer that where beams are specified they should be honored and only in other places the software uses its own algorithm?
2. If the answer to 1. is yes, how does one specify that a specific note should never be beamed?

If the answer to 1. is no, then I think the documentation for beam should explicitly say they are not to be included when useBeams is false. This would then become a validation rule I can add to my validator.

The reason I ask is that I am thinking of a program like MuseScore. Each ChordRest (i.e., "event") in MuseScore has a beam option that defaults to AUTO. (The other options are conceptually "start", "middle", and "end", though there are some secondary beam wrinkles.) The nice thing about leaving them AUTO is that you can easily modify the passage and have the beams reconfigure automatically.

However, another option is NEVER. I'm thinking about if it is possible to encode AUTO (mostly) everywhere but support the occasional NEVER (along with the occasional override with start, middle, end). This would be best practice MuseScore and probably how most files created in MuseScore look. If useBeams == false allowed for the occasional override, a MuseScore export (or re-import) could maintain that best practice.

It's a small matter, but I just thought I would seek clarification. A MuseScore export could certainly create a useBeams == true export and an import could handle it no problems. But such an imported file would be a lot less easy to edit.

[oliverpaddock]

Maybe the solution here to specifying that a note should never be beamed is to create a beam event with just that note? That way if a software runs an auto beaming algorithm and skips all notes that have an explicit beam, it will also skip those single notes that have a beam attached to their id.

The most intuitive way to approach in my head would be to only apply beaming algorithms on notes that aren't explicitly listed in the part measure beams.

[rpatters1]

Single-event beams at the top level (tentatively) are being used for what I call "singleton beams". Single-event beams at the lower level are beam hooks.

I am not crazy about the current design, which I have made no secret of. But having implemented it twice in export and once in import, it works pretty well. I just regret the recursive algorithm that is needed to do it.

[oliverpaddock]

Looking closer at the documentation, it seems like there are only 2 cases:

1. useBeams is true and any events that don't have an explicit beam are unbeamed
2. useBeams is false and any encoded beams should be completely ignored.

I can see the benefits of both requiring all beams to be explicitly encoded as well as allowing some beams to be encoded and let the program figure out the rest of the beams, but the first case (and what seems to be in the documentation) is definitely the simpler case for consuming and emitting applications.

If an application is going to apply beams to specific notes with useBeams set to true, it seems trivial to just explicitly include all beams for the entire score. Maybe the actual expected behavior should be a little more clear in the documentation

[rpatters1]

I agree with your interpretation of 1.

I am not sure about the interpretation of case 2. I have been interpreting beams in a useBeams == false document to mean that those beams override the consumer's default beaming, but every beam does not have to be encoded. I am willing to be persuaded otherwise, though.