Default <score> for an MNX document

[adrianholovaty]

@cecilios made a good point in https://github.com/w3c/mnx/issues/185#issuecomment-960632757_

When the <score> element is present, it could have many alternatives for layouts (full score, alternative displays for the full score, parts, alternatives for the parts,... A consumer application without more information will have to choose an initial layout to display. Are there in current proposal anything (an element/attribute or other) to mark the preferred default layout? Do you think this would be useful or it is not needed and the default layout to use is application dependent?

We should decide whether MNX documents should be able to specify a default <score>. Perhaps we should also provide some guidelines on what consuming software should do in the case of multiple <score> elements — anything from a detailed algorithm to some more vague/light suggestions.

[joeberkovitz]

A related point here — maybe it's the same point? — is that applications may wish to encode a layout without committing to any particular set of pages or system breaks.

For instance, consider a composer creating an initial draft of a piece and working exclusively in horizontal-strip mode in some notation editor. So they haven't committed to any pages or systems, but they may still adopt a particular way of grouping parts. I know this is possible in at least some applications. How would this be encoded?

Perhaps the issue is not about a default <score>, so much as the ability for a <score> to supply a layout only, without pages or systems.

[clnoel]

@joeberkovitz In this case you can simply provide a system-layout and no score. That's a different issue, but I agree that it should be allowable for horizontal-only programs without the concept of system and page breaks.

More on topic, though, I think having a concept of score "types" might be more useful than "default". You might have "full", "reduced", "single-part", "choral", etc. That way, a program can scan through and try to find "full" or failing that "reduced", in order to have systems with as many parts as possible available. I don't know what all the labels should be, or if we even want to go this way.

[notator]

@joeberkovitz asks:

[...] consider a composer creating an initial draft of a piece and working exclusively in horizontal-strip mode in some notation editor. So they haven't committed to any pages or systems, but they may still adopt a particular way of grouping parts. I know this is possible in at least some applications. How would this be encoded?

MNX doesn't have a "horizontal-strip mode", but it does have pages whose dimensions are very flexible...

Any application, that can display notation in two dimensions on a screen, has to have an internal 2-dimensonal coordinate system that it uses to place symbols in the right places. It has to know where it is drawing the symbols, and how big they are. So the app knows how big it needs to make the bounding box (i.e. the page size) on which the symbols are being drawn. That's true, even for incomplete 2-dimensional diagrams, or diagrams that are very wide and only have one system. In other words, I think the composer in your example has (possibly temporarily) committed to one page and one system for the <score>, and that the (default) page dimensions should be stored in the (mandatory) <score> element. Of course, the saved <score> can be re-loaded and edited to contain one or more pages containing one or more systems. An interesting format for screens is one page having fixed width, but with a height that is large enough to contain as many systems as necessary. Scrolling scores vertically on screen is much nicer than scrolling them horizontally. :-)

@adrianholovaty said:

We should decide whether MNX documents should be able to specify a default <score>.

As described above, I think applications can and should always save at least one <score> containing the (default) page dimensions. (<page> should be allowed to override the dimensions, so that "fold-out"s are possible.)

Perhaps we should also provide some guidelines on what consuming software should do in the case of multiple <score> elements.

Fully functional MNX apps are going to have to cope with multiple <score> elements, so they should load one by default, and present the user with a list of the alternatives. We could simply recommend that the first <score> to be defined in the file should be the one to be loaded by default.

[joeberkovitz]

@notator I understand your point, but this is forcing an MNX encoding to commit the application to a particular way of managing "infinite scrolling". That will not fly because the manner of this scrolling is at the very least up to the developer, and quite often up to the end-user (in apps that support both horizontal strips and infinitely-tall "galley" pages).

You haven't explained why it is good to force encoders to invent a fictional page size, and I think we've all agreed that there are many use cases where the document creator has no page size in mind yet - encoding manuscripts, exporting from DAWs, etc. This only benefits applications that for some reason are unable to calculate a default page size. Let such apps perform that reasonable (and not very difficult) task, rather than making MNX encode something that is not meaningful and represents a decision that no one ever took.

[adrianholovaty]

I agree 100% with Joe's comment above. Requiring a <score> element would require MNX producers to jump through unnecessary hoops.

[clnoel]

First, I agree that we should not have to have a score element at all. Any reading programs that care about layout should be able to derive a layout from the parts. Second, the optional score elements should not be required to have a page-size. If we add a system-layout reference to the score element, it becomes possible to define a layout on a score without having to have the concept of pages:

<system-layout id="fullScoreDevelopment">
   ... complicated orchestral grouping layout here ...
</system-layout>

<score default-layout="fullScoreDevelopment"/>

In this way a program that is not scrolling vertically doesn't have to worry about page and system breaks, or even the size that the layout will be, while still tracking what that layout is for the purpose of composing things. Unlimited vertical scrolling would require a page element and system elements for every system, but could still use the default-layout on scroe.

However, this is not addressing what I felt was the initial question posed by this issue. If there is more than one score element, how do we tell which is the main score and which are supplemental (reductions, parts, etc.)?

My proposal to that is to add a "default-score" optional attribute to global, which references a <score> by id. If there isn't one, the first score listed in the document is assumed to be default.

[adrianholovaty]

@clnoel wrote:

My proposal to that is to add a "default-score" optional attribute to global, which references a <score> by id. If there isn't one, the first score listed in the document is assumed to be default.

Thanks for bringing us back on track!

I like the shape of this proposal — nice and simple. I'd just suggest perhaps this attribute should go in the (currently way-underdefined) <head> element? I don't feel strongly about that; just bringing it up so we think it through. Not sure whether the "default score" is the type of metadata that should live in <head>.

[clnoel]

Hah! I forgot we had a <head> element. I like that better. It's where metadata like that belongs.

[notator]

@joeberkovitz

You haven't explained why it is good to force encoders to invent a fictional page size

I haven't done that. The application can widen the page arbitrarily as its being edited, giving encoders the feeling that they are writing on an infinitely wide/high canvas. But at the point where the work is saved, it has a bounding box of a finite size, and that size can be saved in the <score> element. Presumably, such an application would give its users the option to work on an "infinite canvas" when reloading the file. There's no reason to throw away valuable information, that can be used in other ways when importing the file.

[adrianholovaty]

@notator For the specific point of whether <score> should be required, please open a new issue rather than getting us off-topic on this one. This issue (252) is about how to specify the default score for a document.

[notator]

This issue (252) is about how to specify the default score for a document.

That's what I'm doing! Or have I completely misunderstood something? Maybe you could explain what you think the "default score" is?

[clnoel]

@notator Reread the original post. "Default score" in this question is not what happens when there is no score defined, or no layout on that score, but what happens when there are many scores defined and a program needs to pick one to display.

[joeberkovitz]

I've added https://github.com/w3c/mnx/issues/266 to capture the question of whether scores must have pages. I believe @notator's point is relevant to that question and can be taken up there.

[notator]

In https://github.com/w3c/mnx/issues/252#issuecomment-972803837 I describe why I think MNX files can, and should, contain at least one <score>. I then said:

Fully functional MNX apps are going to have to cope with multiple <score> elements, so they should load one by default, and present the user with a list of the alternatives. We could simply recommend that the first <score> to be defined in the file should be the one to be loaded by default.

[notator]

According to the <score> documentation:

MNX documents are not required to contain a <score> element. If <score> isn't provided, the default rendering behavior is to include all parts — in the same order in which the <part> elements appear in the document — with line breaks and page breaks determined automatically by the consuming software.

I think that's okay. We need to verify that this works, when we start looking at <part>'s internal structure again. So I now agree that <mnx> need not contain any <score> elements.

However, when <mnx> does contain one or more <score>s (the subject of this issue), I still think that the default <score> should simply be the first one in the file. All <score> elements, including those that contain <page> elements and those that don't, now have a well defined layout.