Can scores specify a system layout without pages?

[joeberkovitz]

Do we want to allow scores to specify layouts without pages? If the answer is yes, then it likely follows that page dimensions are optional for a <score>. But if a score must always have pages, then perhaps we need scores to specify a physical page size for this to be meaningful.

[joeberkovitz]

We can solve this question with a thought experiment. Let's consider the case of an author who's composed a score entirely in infinite-strip or infinite-galley mode, in some application that does not care about pages (say, a DAW). We could say, the encoder just doesn't need to include any <score> element at all as there aren't pages: there has never been any attempt to compute or define system breaks.

But by doing this, we would preclude any ability for that document to encode layouts. And without ever leaving their infinite strip, it's very possible that our author went ahead and defined part groups, staff spacings, etc.: things that a layout describes. So to encode this document properly, we'd need to have a score with no pages, but with a layout.

[clnoel]

In https://github.com/w3c/mnx/issues/185#issuecomment-973019614 I just proposed the following. It makes layout and optional attribute on score. If we also make all the measurements (width, height, etc.) optional, then that addresses this issue. You can have a score with no pages or system breaks, but with a layout.

...
    <part id="example">...</part>

    <system-layout id="exampleSystemLayout">
        <part-layout part="example" />
    </system-layout>

    <score name="example" width="2200" height="373" margins="159 76 135 272" gap="20" layout="exampleSystemLayout"/>
    ...

[joeberkovitz]

This seems fine as an encoding mechanism. We can close this issue once it's agreed that the dimensions be optional.

[notator]

I'm currently advocating the following nesting hierarchy for MNX files (see https://github.com/w3c/mnx/issues/185#issuecomment-969380912 and Issue #252):

1. <mnx> must contain at least one <score>
2. <score> must contain at least one <page>
3. <page> must contain at least one <system>
4. <system> must reference a <system-layout>
5. <system-layout> must contain zero or more <group-layout>s and/or zero or more <staff-layout>s
6. <group-layout>s are recursive, but always bottom-out with a <staff-layout>
7. <staff-layout> must contain either a <voice-layout> or a <part-layout>
8. <part-layout> references a <part>

As detailed in https://github.com/w3c/mnx/issues/185#issuecomment-972749813, I think the <page>, <system> and <voice-layout> elements can be implicit in the <score> if there are only one of each. The code

    ...
    <part id="example">...</part>

    <score name="example" width="2200" height="373" margins="159 76 135 272" gap="20">
        <part-layout part="example"/>
    </score>
    ...

means that the implicit container hierarchy is as follows: <score> contains one <page> that contains one <system> that references one <system-layout> that contains one <staff-layout> that contains one <part-layout> that references a single <part>.

So the simple answer to this issue's question is no. A score must contain at least one (possibly implicit) page, and therefore needs to be given (at least relative) dimensions, as in the code example above. (See also https://github.com/w3c/mnx/issues/185#issuecomment-973891469.)

@joeberkovitz' thought experiment:

Let's consider the case of an author who's composed a score entirely in infinite-strip or infinite-galley mode, in some application that does not care about pages (say, a DAW). We could say, the encoder just doesn't need to include any <score> element at all as there aren't pages: there has never been any attempt to compute or define system breaks.

Lets take the case of the author having created a single <system> (without line-breaks) that eventually references a single <part>. Line-breaks are just complications that DAWs don't need. Since I think the above conditions hold, I think the <score> saved in the MNX file can be saved in the above, reduced form. In particular, note that

• If the DAW application can display two-dimensional CWMN graphics, then it can also calculate the dimensions it needs to save in the <score>.
• the implicit <system-layout> adds no further information to the information contained in the <part>, so <part> must contain all the information necessary to reproduce the graphics displayed by the DAW app.
• the DAW's temporal information (e.g. MIDI info) could also be stored in the <part>. But that's something for a new issue...

@joeberkovitz again:

But by doing this, we would preclude any ability for that document to encode layouts. And without ever leaving their infinite strip, it's very possible that our author went ahead and defined part groups, staff spacings, etc.: things that a layout describes. So to encode this document properly, we'd need to have a score with no pages, but with a layout.

That's not quite true: If the DAW app is capable of encoding layouts (part groups, staff spacings etc.) then it can encode them explicitly in a <system-layout> for a single <system> in the single (implicit) <page> in the <score>:

    ...
    <part id="part1">...</part>
    <part id="part2">...</part>
    <part id="part3">...</part>
    // more parts

    <system-layout id="system-layout1">
        // code describing the system layout
    </system-layout>    

    <score name="example" width="2200" height="373" margins="159 76 135 272" gap="20">
        <system measure="1" layout="system-layout1" />
    </score>
    ...

[joeberkovitz]

We have the following documented use case for MNX: Editor wants to manually transcribe sheet music to digital encoding format. The input could be hand-written music from a set of irregular pieces of paper. There is no application to create the MNX encoding: a human is doing it. Are we going to require that this human user has to make up a page size (they likely have none in mind), or calculate one? Either option seems absurd.

I feel like what's missing here is a rationale for a score needing to contain a page with dimensions. I get that it makes it easier for some application that has trouble calculating a default display size, but that is not a good reason: any app should be able to do that. The above proposal merely explains how a single page with a single system can be encoded, and asserts that it is necessary — but it doesn't say why. The information is not "valuable" because it can be recalculated at will by any application, in a way that suits that application.

Could we perhaps hear from others on this question? I don't think further back and forth is going to be helpful right now.

[dspreadbury]

I think it should be valid not to define a fixed page size in an MNX document. It ought to be valid to list the parts, perhaps define a single nominal grouping that could be used for the whole span of music, but not provide any system formatting or page layout information at all. Enforcing the use of a single page of fixed but arbitrary size seems pretty counter-productive to me, so I am in favour of @joeberkovitz 's proposal that it should be possible to define a <score> so that we can define part groupings, but it should not be necessary to define any pages.

[cecilios]

In my opinion page size is not necessary, specially for web oriented applications. For other cases, the application should be free to use whatever it prefers (or some user default page size) if page size is not specified.

[samuelbradshaw]

Sorry that I haven't fully kept myself in the loop of previous decisions – if I'm not following correctly, let me know. :)

The documentation for a <page> says that it represents "a single page of music — either printed (as on paper) or digitally rendered." If I understand correctly, this is equivalent to a web "page" or a "page" of a PDF – i.e. the box that content is drawn in. Semantically, it doesn't make sense to me for a document to display something but not have a page – a score without a page is like a PDF document with no pages, or a browser window without a web page to display. So, I'm in favor of making it required to have one or more <page>s in a score, OR, we could allow a document with no pages to validate, but it wouldn't display anything because there are no "boxes" to draw content in. Maybe not having a page could be valid for a document intended for audio playback only. Am I correct that a <page> is a box to draw content in, and a <score> is a container for a set of pages?

That said, I don't think there's any reason to require a page size to be set. Think of a web page – the width and height is determined on the fly based on how the user resizes the browser window. Despite the authoring program's knowledge of how to lay out the score, there's no way for it to know in advance what size the user's window will be – if it will be wider than it is tall, etc.

[joeberkovitz]

Interesting idea. It leads me to wonder, if we only have one page, and it has no dimensions, what information is conveyed by the <page>element? It would have no attributes and no children. Question: Is leaving it out entirely, the same as permitting one page to be included but with no information describing it? I’d say it doesn’t matter in a practical sense what the answer is to that question. Either way, an app is free to display the score any way it likes, so long as it conforms to the prescribed system layout.

[ahankinson]

It would have no attributes and no children.

An alternate method of encoding 'pages' is to insert "milestone" page-begin (<pb />) elements to provide renderers with the ability to break the content as needed. This means that pages are not structural elements -- they do not 'contain' any musical data, and as such are not integral to the encoding -- while still providing page-rendering hints. These milestone elements do not have children (they're the functional equivalent to the <br /> in HTML).

This is the current approach taken by MEI and TEI. (There is also <sb /> for system-begin and <lb /> for text line-begin).

We use "begin" instead of "break" to mark the start of a new page, rather than the end. This is because sometimes you want content to flow between explicit breaks with no specific locations, but you do want to insert a specific break before the start of new content -- the beginning of a recapitulation, or an instrumentation change, or to avoid specifically awkward notation passages. In actuality there is no real difference -- a beginning of a new page is also an ending of the previous one.

That said, the MEI community has identified places where structural page elements are useful. We wrote a paper about this a few years ago. I think the specific implementation has moved on from that described in the paper, but the motivations are still valid.

Furthermore, Verovio can render according to the page-based layout if encoded, it can ignore the encoded page layout, or it can automatically impose a page layout for encodings that have none. You can see this behaviour on the Verovio editor*: Choosing the options under the 'View' menu shows how a score would be rendered as a document, or in a responsive layout.

It seems to me that if you have all these -layout elements, a page-layout element, outside of the musical element hierarchy, and perhaps in the <head> would make sense? Renderers could ignore or read the data as they like, and it would be optional for those scores that did not specify a page layout. This could contain the margins, footers, etc. Then <pb /> elements in the content (or their equivalent) for where you want to force a page break.

* The editor is currently a proof-of-concept, so don't think that this default layout is the best that it can look! The document layout shown isn't adjusted at all, so the page margins look really small. There are controls that could be adjusted to make this look better.

[notator]

@joeberkovitz

We have the following documented use case for MNX: Editor wants to manually transcribe sheet music to digital encoding format. The input could be hand-written music from a set of irregular pieces of paper. There is no application to create the MNX encoding: a human is doing it. Are we going to require that this human user has to make up a page size (they likely have none in mind), or calculate one? Either option seems absurd.

Transcribing sheet music to a digital encoding format would presumably be done by entering it into a music notation editor. And MNX is the digital encoding format it creates. I can't imagine any human trying to transcribe sheet music directly into MNX (or any other digital encoding format) without such an application! As explained above, the human author does not have to decide on the page size (unless required to do so by the application). Users may have the illusion that they are working on an infinite canvas, but the canvas always has a finite bounding box when saved.

[notator]

@joeberkovitz again:

I feel like what's missing here is a rationale for a score needing to contain a page with dimensions.

Including a <score> element, complete with (relative) dimensions and styles, and (possibly implicit) page(s), creates a format that is a replacement for all the proprietary formats currently used by notation editors.

So there is no need to create a replacement for MusicXML. Interchange formats are redundant.

Can anyone provide a use-case for a format that doesn't contain a <score>?

[adrianholovaty]

I'm in favor of allowing layouts without requiring pages.

Perhaps my own notation app, Soundslice, can provide an example. It's a web-based sheet music viewer and editor, and the notation positioning is dynamic, based on your screen size, zoom level, selected instruments, focus mode, etc.

Internally, our notation data is manipulated by two separate systems (for different use cases):

• Rendering is done by client-side JavaScript. This system knows about all of the (dynamically generated) notation positioning.
• Import/export is done by server-side Python. This system doesn't know or care about notation positioning, because the positioning is always calculated on the fly in JavaScript. However, this system still knows about "layout-ish" information — namely, the part order, whether grand-staff brackets are used, etc.

So if we were to use MNX for our notation data, we'd still want to encode the layout, but it would feel unnatural to require pages. It would feel like we were being made to jump through hoops to represent a concept that we don't actually use or care about.

[notator]

@adrianholovaty Would you be happy with: " <mnx> must contain either one-or-more <score>s (as described above, for conventional use cases) or one-or-more <system-layout>s (for web-based applications)"? That would be quite easy to arrange, especially if we can share <system-layout> code across the options. The disadvantage of that would be that applications would need to check if the file is intended for conventional or web use. But we could think about an elegant way to solve that problem...

A couple of questions:

1. Are you happy with the proposed content of <system-layout>?
2. How do you manage the changing of <system-layout>s? Maybe they don't change?

[adrianholovaty]

@notator No, I don't think we should require either of those. As has been established in various comments by me and Joe (and maybe others?), a music notation rendering engine should be able to generate sensible defaults for positioning and layout. Of all the things that a rendering engine has to do, that is among the least difficult. I'd even call it table stakes.

To your other questions: I can answer those in the appropriate separate issues, so as not to bog down this thread. (I'm trying to set a good example that I hope you'll follow!)

[notator]

Okay. I need a bit of time to think about how to generate sensible defaults. My first reaction is that there are going to be different requirements for conventional and web-based MNX types. We'll see.

(later) I think defaults have to be set by applications, not the format. The alternatives described in https://github.com/w3c/mnx/issues/266#issuecomment-975501535 are still possible.

[joeberkovitz]

I think @ahankinson's suggestion of milestone-based system/page break elements is right on and probably even essential. It's common for authors to specify "must begin a new system at this measure", a flag which is honored on the fly when an application generates a run of pages. While I don't think we should spec this fully here (and I hope he will file an issue for it), it does underline the fact that pagination is often dynamic. So... MNX will need to be able to talk about page layouts even if there are no specific <page> elements (e.g. placement of page numbers, headers, footers, etc.).

So ultimately we may need a <page-layout> although I would propose grouping it along with system layouts under a new <layouts> container as this benefits the styling proposal - see https://github.com/w3c/mnx/issues/263#issuecomment-975686575 for an example of why this helps.

[clnoel]

At first I was opposed to this idea. Most of the point of the layouts was to avoid putting this kind of information in the parts. However, upon reflection, I think I can support an optional break attribute on measure-global, with the following values:

• never: Do not break here when making a new layout.
• optional: (default) Breaks are allowed here.
• recommended: Prefer to break here rather the next or previous measure when making a new layout.
• required: Break here every time. If the current layout doesn“t say to do so, form a new system horizontally aligned with the previous system.

never would probably only be used in pieces where measures do not align across parts, which is out of scope for V1. recommended would be used for logical break points like rehearsal marks, and required for the start of a coda.

If we want to move this to a separate issue, I'm fine with that.

[joeberkovitz]

@clnoel that's a good initial proposal and let's move this elsewhere so we leave the topic as originally posted. I have a comment but I'll make it in the new thread.

[notator]

Quoting the original questions raised by this issue:

Do we want to allow scores to specify layouts without pages?

My position on this has changed since the above comments. I now agree that the answer is yes. To be precise: the <score> element can have a layout attribute, even though it contains no <page> and no <system> elements (i.e. no mandatory system breaks). (see https://github.com/w3c/mnx/issues/185#issuecomment-977879004) If, as @clnoel, @joeberkovitz and I agree, <mnx> contains a <layouts> element containing the layout element definitions, then a <score> containing a single <part>, but no system breaks, would look like this inside <mnx>:

<mnx>
    <global>...<global>
    <part id="part1">...</part>
    <layouts>
        <system-layout name="system-layout1">
            <part-layout part="part1" />
        </system-layout>
    </layouts>
    <score ... layout="system-layout1" />
</mnx>

The "..." in <score> stands for the score's dimensions. These could be defined directly, as in <score width="2200" height="373" margins="159 76 135 272" gap="20" layout="systemLayout1"/> or using style information in some way. Note that gap is one of the dimensions. It defines the default staff height, by defining the vertical distance between two of the default staff's stafflines. I have a proposal for defining the distances connecting the various spatial areas inside a page, including margins, the vertical distance between systems etc., but will do that in a separate issue. Styles are covered in #263, so the details of how to save the dimensions are off-topic here.

If the answer is yes, then it likely follows that page dimensions are optional for a <score>.

I'd like to argue that, even though a <score> can be defined without defining system breaks, its dimensions should always be mandatory. Any application that displays a score in two dimensions must know the score's (relative) dimensions. Even web applications that don't care about system breaks must know the relative sizes of the dimension parameters, including the gap size, when the notation is displayed without system breaks

Since the dimensions are always available to applications that create MNX files, they can, and should, always be saved. Why make life difficult for consuming applications (which might also be the original application)? I could be convinced that the dimensions are optional, if anyone can provide an example of a program that creates a <score> without knowing its (relative) dimensions.

Notes:

1. Applications that consume MNX files, but don't care about graphical rendering will simply ignore the <score>'s dimensions. This means that they can't change the dimensions or create new ones. So they can't save new MNX files.
2. The <system-layout>, referenced by the <score>'s layout attribute, can include <staff-layout> elements that have different styles, including different gap sizes.

---

Looking back at the original question again:

Do we want to allow scores to specify layouts without pages?

I'm not sure if it would be interesting for web-based applications, but more than one layout could be defined for web-based <score>s as follows (see https://github.com/w3c/mnx/issues/185#issuecomment-977879004):

    ...
    <part id="part1">...</part>
    <part id="part2">...</part>

    <layouts>
        <system-layout id="sysLayout1">
            <part-layout part="part1" />
        </system-layout>
        <system-layout id="sysLayout2">
            <part-layout part="part1" />
            <part-layout part="part2" />
        </system-layout>
    </layouts>

    <score ...  layout="sysLayout1">
        <system-layout-change measure="19" layout="sysLayout2"/>
    </score>
    ...

Would the change of <system-layout> at measure 19 mean that

1. there must be a system break at that point?
2. the dimensions in <score> would only apply to measures 1-18, and new dimensions need to be defined on <system-layout-change>?

[joeberkovitz]

When @adrianholovaty closed #270, recognizing the lack of support for <score> being mandatory, this recognized that we will have MNX documents that lack a <score> and therefore have no stated dimensions. This dispenses with the unjustified assertions above that:

Any application that displays a score in two dimensions must know the score's (relative) dimensions. Even web applications that don't care about system breaks must know the relative sizes of the dimension parameters, including the gap size, when the notation is displayed without system breaks Since the dimensions are always available to applications that create MNX files, they can, and should, always be saved. Why make life difficult for consuming applications (which might also be the original application)?

These claims have never been true for applications in general, whether web-based or not, and I've pointed out repeatedly that some MNX files are created by humans directly from analog artifacts. Likewise, with MusicXML today, pretty much any applications can import a score with no dimensional information and show it perfectly well based on their own defaults. We should not be taking a step backward.

Even prior to closing #270, the posts on this issue have broadly agreed that even when a <score> element is present, it can reference a layout without score dimensions. Leaving aside my original arguments, please see here, here, here and here.

So we now seem to have unanimous agreement that <score> elements may cite a layout without pages, and unanimous-minus-one agreement that they may also omit dimensions. @adrianholovaty what's your opinion on next steps here?

[adrianholovaty]

Catching up on this — I agree with the consensus here that <score> should be able to use a layout without needing to have pages or dimensions. Let's do it!

I've put together pull request #271 with the appropriate changes to the spec, which are reasonably small. Do those changes properly reflect the consensus here?

[cecilios]

What about the <layouts> container. Is it finally added or removed?

[clnoel]

I think we're probably adding that in #185.

[adrianholovaty]

All right, pull request #271 is now merged, so this particular issue is closed!