Add repeats and jumps to spec #190

adrianholovaty · 2020-07-21T09:59:40Z

This pull request adds the following definitions to the MNX-Common spec:

<ending>
<repeat>
<coda>
<segno>
<jump>

Preview | Diff

clnoel · 2020-07-21T15:25:08Z

Now that I'm looking at this after a break, I see the following:

Since these are "directions" we probably need to allow "Attribute Groups: Direction attributes"
- Default "Measure location" for endings "Stop" and "Discontinue" and repeat "end" is actually the end of the measure (not locatoin 0).
We need to be able to handle more than one segno and coda in a piece without confounding the jump direction. Double-segno, Double-coda, and "Coda II" are rare but not unheard of. If that needs to be a new issue/PR, I'm okay with that.
The jump direction needs optional text content (default text depends on type)

adrianholovaty · 2020-07-21T18:56:53Z

@clnoel Thanks for giving it a read!

Since these are "directions" we probably need to allow "Attribute Groups: Direction attributes"

Default "Measure location" for endings "Stop" and "Discontinue" and repeat "end" is actually the end of the measure (not locatoin 0).

I was conflicted on this one. Technically a measure location is meaningless for a repeat, ending or jump; see the sentences beginning with "This element applies to the containing measure" in the diff.

We need to be able to handle more than one segno and coda in a piece without confounding the jump direction. Double-segno, Double-coda, and "Coda II" are rare but not unheard of. If that needs to be a new issue/PR, I'm okay with that.

Yes, great point. I discussed this with Daniel and Michael in our biweekly video chat today, and we came to the conclusion that the best solution would be to allow multiple segnos/codas in the same piece but require unique identifiers to disambiguate. I'll update this pull request with that change...

The jump direction needs optional text content (default text depends on type)

We're going to punt on this particular issue at the moment, because we need to be able to encode things like "D.S. al [CODA SYMBOL]" (i.e., with embedded graphics). The eventual solution will need to handle that, plus possibly fonts and other stylistic choices. This will likely be addressed by a larger-scale focus on presentation/style.

notator · 2020-12-08T20:58:09Z

Oops, sorry, I originally posted this in issue #207, but now see that it belongs here.

I'm currently working on converting the Repeats examples in MNX by Example to SVG using my MNXtoSVG application.

According to Gardner Read's Music Notation (1974), page 227:

MusicXML repeats always seem to be barline types, which would make the above constructions impossible.
So: a couple of questions for @mdgood:

Does MusicXML allow repeat signs to be placed as in the above examples? Maybe I've missed something...
If not, is it going to support this in a future version?

Whatever the answers, this is standard practice, so MNX needs to support it, and we need a corresponding example (or two) in MNX by Example. The obvious way to do it in MNX would be to provide an optional measureLocation attribute on the <repeat> element. This would default to 0 for <repeat type="start" /> and to the duration of the measure for <repeat type="end" />.

See also the comment in §6.8.6 The repeat element in the Draft Spec:

[The repeat element] Applies to the containing measure (i.e. does not belong to a <barline>). Thus, "start" means a repeat starting from the beginning of this measure; "end" means a repeat ending at the end of this measure.

mdgood · 2020-12-09T01:08:33Z

@notator The first example is one of the aspects of graphical appearance that is not notated explicitly in MusicXML 3.1, similar to the exact location of cautionary key signatures. Notation applications generally handle this situation automatically without needed guidance at the appearance level from the MusicXML representation. The information is represented semantically, so the beginning of the repeat and the new time and key signatures would all be represented at the start of the second measure. Notation applications will then automatically generate the desired display.

The second example can be represented in MusicXML 3.1 using a <barline location="middle"> element in the middle of the measure. Alternatively you can have the repeat start a new measure, leaving the measures on either side of the repeat short of the complete duration of the time signature.

notator · 2020-12-09T10:47:24Z

@mdgood Thanks. Understood.
That means we only need an MNX by Example example for mid-measure repeats. The first case can be left for consuming applications to sort out.

For this PR: As explained above, I'd like to propose that the MNX <repeat> element be given an optional location attribute. This would default to 0 for <repeat type="start" /> and to the duration of the measure for <repeat type="end" />.

Below is how I want to code the following example in MNX. Perhaps you could provide the equivalent MusicXML 3.1 code so that it can be included in MNX by Example?

<mnx>
    <global>
        <measure>
            <directions>
                <time signature="3/4"/>
            </directions>
        </measure>
        <measure>
            <directions>
                <repeat type="start" location="1/2"/>
            </directions>
        </measure>
        <measure />
        <measure>
            <directions>
                <repeat type="end" location="1/2"/>
            </directions>
        </measure>
        <measure/>
    </global>
    <part>
        <part-name>Music</part-name>
        <measure>
            <directions>
                <clef sign="G" line="2"/>
            </directions>
            <sequence>
                <event value="/2d">
                    <note pitch="C5"/>
                </event>
            </sequence>
        </measure>
        <measure>
            <sequence>
                <event value="/2">
                    <note pitch="E5"/>
                </event>
                <event value="/4">
                    <note pitch="D5"/>
                </event>
            </sequence>
        </measure>
        <measure>
            <sequence>
                <event value="/2d">
                    <note pitch="G5"/>
                </event>
            </sequence>
        </measure>
        <measure>
            <sequence>
                <event value="/2">
                    <note pitch="G5"/>
                </event>
                <event value="/4">
                    <note pitch="F5"/>
                </event>
            </sequence>
        </measure>
        <measure>
            <sequence>
                <event value="/2d">
                    <note pitch="E5"/>
                </event>
            </sequence>
        </measure>
    </part>
</mnx>

adrianholovaty · 2020-12-09T11:10:40Z

@notator I agree it would be good to add an example for that case.

For the actual markup, I'm inclined to prefer the simple approach Michael suggested: "have the repeat start a new measure, leaving the measures on either side of the repeat short of the complete duration of the time signature." So no special markup would be needed for this case.

notator · 2020-12-17T12:16:45Z

Both @clnoel and the co-chair have reservations about the way Jumps are currently being coded in MNX by Example, and I need some clarification before implementing them in my MNXtoSVG application.
The co-chair says:

We're going to punt on this particular issue at the moment, because we need to be able to encode things like "D.S. al [CODA SYMBOL]" (i.e., with embedded graphics). The eventual solution will need to handle that, plus possibly fonts and other stylistic choices. This will likely be addressed by a larger-scale focus on presentation/style.

To answer that, and drawing on @clnoel's comments above and in #174 (comment), I'd like to make the following proposal:

There should be two basic elements: <target> and <jump>, both of which can be defined in <global><measure><directions>.

The <target> element is simply a place to jump to (like a "label" in many programming languages).
The <jump> element can perform one of three different actions when encountered in a performance:
- continue,
- goto somewhere
- stop.

The <jump> actions will be represented as elements in an ordered list inside the <jump> element, each of which is used once (in order) as the <jump> is repeatedly executed. The examples below should make this clearer.

The simple dal Segno example from MNX by Example:

would be coded like this:

<mnx>
    <global>
        <measure>
            <directions>
                <time signature="4/4"/>
            </directions>
        </measure>
        <measure>
            <directions>
                <target id="target1" text="&segno;" />
            </directions>
        </measure>
        <measure/>
        <measure/>
        <measure>
            <directions>
                <jump text="D.S."> 
                    <goto target="#target1" />
                </jump>
            </directions>
        </measure>
    </global>
    ...
</mnx>

Remarks:

I can't find any official HTML token strings for the segno or coda characters apart from the numeric ones, but we could use the HTML pattern anyway in MNX to make legible equivalents. In other words, we could use ("&segno;") for the segno character, and ("&coda;") for the coda character. Possibly, such strings have been defined officially for all the unicode music symbols, but I haven't found them.
Probably, MNX will eventually be able to contain CSS recommendations for element and attribute classes (also for coloured noteheads etc.). In addition to the simple segnos and codas defined here, it would also be possible for other objects (such as rehearsal numbers) to be targets, and it would be quite possible to define a <target> class attribute that would take care of the appropriate styling. However, I think that's a separate issue. Maybe we should start addressing it here. Maybe not. (?)
<target> elements are (like <repeat type="begin"> placed, by default, at the beginning of the measure in which they are defined.
<jump> elements are (like <repeat type="end">) placed, by default, at the end of the measure in which they are defined. Note that there could be both a <jump> and a <repeat type="end"> at the end of a <measure>. In that case, the <repeat> would always be executed (as many times as it says) before executing the <jump>.
the target of a <goto> element is a measure location, so could either be an ID (as above) or a measure index (In the above case, the goto would be <goto target="2:0" /> and the target ID would be superfluous.)

The D.S. al Fine example:

would be coded like this:

<mnx>
    <global>
        <measure>
            <directions>
                <time signature="4/4"/>
            </directions>
        </measure>
        <measure>
            <directions>
                <target id="target1" text="&segno;" />
            </directions>
        </measure>
        <measure>
            <directions>
                <jump text="fine">
                    <continue />
                    <stop /> 
                </jump>
            </directions>
        </measure>
        <measure/>
        <measure>
            <directions>
                <jump text="D.S. al Fine"> 
                    <goto target="#target1" />
                </jump>
            </directions>
        </measure>
    </global>
    ...
</mnx>

And a D.S. al Coda (not yet in MNX by Example)

would be coded like this:

<mnx>
    <global>
        <measure>
            <directions>
                <time signature="4/4"/>
            </directions>
        </measure>
        <measure>
            <directions>
                <target id="target1" text="&segno;" />
            </directions>
        </measure>
        <measure>
            <directions>
                <jump text="al Coda">
                    <continue />
                    <goto target="#target2" /> 
                </jump>
            </directions>
        </measure>
        <measure/>
        <measure>
            <directions>
                <jump text="D.S. al Coda"> 
                    <goto target="#target1" />
                </jump>
            </directions>
        </measure>
        <measure/>
        <measure>
            <directions>
                <target id="target2" text="&coda;" />
            </directions>
        </measure>
    </global>
    ...
</mnx>

(This example is like the one in the Finale documentation. Note that Measure 6 never gets played.)
@clnoel mentions "double-segno", "double-coda", and "Coda II" forms. I think these, and other more complex routes through the score, could also be coded using the above elements. A double-segno would simply be a <target text="&segno;&segno;">.

Questions:

Do we want to allow mid-measure <target> and/or <jump> elements? I think that would increase their power considerably. It could easily be done (as with <repeat>s) by giving them an optional location attribute.
Should target ID reference strings always begin with the '#' character (as in HTML)? That's what the Draft Spec says, but I don't think we've been doing that consistently in MNX by Example.
As it stands, the text attributes of both <target> and <jump> can contain newlines ('\n'). Is that okay?

clnoel · 2020-12-17T15:16:48Z

I approve of the general outline of these jumps and targets. I would prefer to allow mid-measure jumps and targets, even if they are rare.

I think that we don't need the # in the targets, but I'll defer that to someone who is more familiar with general XML/CSS styles.

We should allow newlines. Sometimes space gets crunched and you need to put things on two lines. Although rare, there's no reason to exclude the possibility.

As a side note, I really like the idea of using "fake" HTML special-symbol notation for common musical symbols that end up in text directions, like segno and coda. It solves so many issues that we have to scramble around. And lets different reading applications apply whatever algorithm they need, like changing to their special music font, in order to properly display it.

--Christina

ahankinson · 2020-12-18T14:37:15Z

The hash fragment format (identifiers starting with a #) ties an ID in with the URI specifications for identifying sub-parts of a document. Seeing an ID reference start with a hash fragment is effectively shorthand for saying "this ID in the current document" (as opposed to "this ID in some other document on the web", which you can also do.) This is why it's used in HTML; it allows you not just to link to a page, but also to a specific part of that page.

In MEI we recommend using hash fragments for identifying IDs, since there is the idea that you can reference elements in other documents (for example, you can talk about a specific note or measure in some other URI-referenceable notation encoding.) It also ties in with current research on Linked-Data friendly approaches to music notation encoding, and transformations to LD-friendly formats like RDF and Turtle.

It also helps if you want to tie IDs of musical elements to SVG renderings, and then to CSS styling of the SVG; a consistent ID method means you can carry the ID through the transformations, and then target specific musical encoding elements with standard CSS selectors.

Basically, using the hash fragment method for IDs is not an XML requirement, but it helps tie in to lots of other standards and formats out there.

ahankinson · 2020-12-18T14:53:12Z

You can put newlines in attributes, but most standard XML parsers will remove them and normalize to a single space, since the newline character is not part of the XML spec. (\n has no real meaning in XML). It's the same behaviour as in HTML. If you put:

<p>
this is a bunch of text
that has a line break in it.
</p>

It will render in one line, with a space between "text" and "that", and the \n line ending will be ignored.

notator · 2020-12-19T10:20:50Z

@ahankinson Many thanks! :-)

'#' characters:
All points taken. Enabling a link from an external document seems to me the best reason for using an ID! :-)
So, when the current PR backlog has cleared, I'll submit a PR (for both the Spec and MNX by Example) to the effect that MNX recommends the use of a '#' character at the beginning of each reference to an internal ID. Or should MNX insist on such a usage?

'\n' characters:
As my proposal stands, its only going to work for one-line texts. That's okay for the usual cases, but more labyrinthine paths though the score (1st goto, 2nd goto etc.) would need some kind of multi-line capability.
I think that would be best realised not in the <jump> element (which could have text=""), but by having a separate, general purpose, multi-line <instruction> direction, that could be used for other kinds of performance instruction as well.
The current <instruction> element also only supports one line of text.
We need something more like:

<instructionBlock id="ib1" align="right" location="4/4">
    <textLine>text of line1</textLine>
    <textLine>text of line2</textLine>
    <textLine>text of line3</textLine>
    ...
</instructionBlock>

Other things:

I'm not really happy with "jump" as the element name. Its only really a "jump" when its a "goto". So I'd like to refactor it to "branch" or "fork". Has anyone got any better ideas, or would anyone prefer to keep "jump"?
I think this PR should be rejected, but that we should continue to discuss the alternatives here.
Having a general purpose <jump> or <branch> element would help a lot with scores like this one. Happy Christmas everyone!

notator · 2020-12-20T10:33:32Z

I now think the <jump> element should be called a <switch>. As in C-like programming languages, it presents a list of possible actions. In the present case, the actions are performed in sequence, but the element is still an n-way switch.

Also worth mentioning explicitly here: Implicit in @ahankinson's reply about '#' characters is that <goto>s can be used to switch to different files...

I'd like to replace the current <instruction> element in the Draft Spec by more generalised <text> and <textBlock>s. Such a proposal would make the <target> element redundant, but its rather off-topic for this PR, so I'll keep it for later.

ahankinson · 2020-12-21T11:42:09Z

BTW, Entity entries can be used to map custom HTML entities to Unicode codepoints:

<!ENTITY segno CDATA "&#x1D10B;"

With these types of entries in the top of your XML file, you can use custom Unicode code points for any symbol. This means you could also map them to SMuFL code points for some files, and standard Unicode points for others.

https://www.w3.org/TR/html4/sgml/entities.html

You could also adopt the MEI method of setting custom glyphs, which is to specify the code point along with some form of authority for mapping that to a set of points. This can be seen with the @glyph.* set of attributes, where you can use a URI to uniquely identify a set of glyphs, and then @glyph.num to identify the numeric point of that glyph.

notator · 2021-01-05T11:29:07Z

It occurred to me that we could also add a <pause> option to the available actions in the <switch> (aka <jump>) element:
Its actions list would then contain the following options in any order:

goto somewhere
continue,
pause
stop.

This would complete the access to the standard set of controls used by a performing application.
The <pause> option would effectively click the application's pause button, and wait for user interaction. It might make presentations a more enjoyable experience (for the presenter) if pauses could be built into the file...

There may be other performance actions that could be programmed in this way. Changes of speed or loudness, for example....

adrianholovaty · 2024-03-07T14:30:29Z

Closing this because it's not relevant anymore:

MNX uses JSON, and this pull request uses XML
We've already implemented alternate endings, repeats and segnos

We haven't yet implemented the following:

Segno
Support for multiple jumps (e.g., multiple segnos in the same piece)

I'll open separate issues for these two matters so we don't lose track of them.

adrianholovaty added 2 commits July 21, 2020 11:36

Add ending and repeat sections to the MNX-Common spec

6ceb747

Added coda and jump

7f1ef51

notator mentioned this pull request Dec 8, 2020

Repeats #207

Closed

This was referenced Jan 7, 2021

Actions #214

Closed

Texts #215

Closed

This was referenced Jan 20, 2021

Create XSD schema document #73

Closed

MNX by Example: Mid-measure repeats #222

Closed

MNX by Example: Beams (with inner grace note) #225

Closed

notator mentioned this pull request Mar 4, 2021

<part-name> element feels inconsistent with rest of MNX schema #227

Closed

ahankinson mentioned this pull request Aug 11, 2021

Provide a way to encode system breaks and page breaks #57

Closed

notator mentioned this pull request Dec 18, 2021

Multi-line text blocks #278

Open

adrianholovaty closed this Mar 7, 2024

adrianholovaty deleted the spec-repeats-jumps branch March 7, 2024 14:30

This was referenced Mar 7, 2024

Segnos #324

Open

Multiple jumps of the same type #325

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add repeats and jumps to spec #190

Add repeats and jumps to spec #190

adrianholovaty commented Jul 21, 2020 •

edited by pr-preview bot

Loading

clnoel commented Jul 21, 2020 •

edited

Loading

adrianholovaty commented Jul 21, 2020 •

edited

Loading

notator commented Dec 8, 2020

mdgood commented Dec 9, 2020 •

edited

Loading

notator commented Dec 9, 2020

adrianholovaty commented Dec 9, 2020

notator commented Dec 17, 2020 •

edited

Loading

clnoel commented Dec 17, 2020

ahankinson commented Dec 18, 2020

ahankinson commented Dec 18, 2020 •

edited

Loading

notator commented Dec 19, 2020

notator commented Dec 20, 2020 •

edited

Loading

ahankinson commented Dec 21, 2020 •

edited

Loading

notator commented Jan 5, 2021 •

edited

Loading

adrianholovaty commented Mar 7, 2024

Add repeats and jumps to spec #190

Add repeats and jumps to spec #190

Conversation

adrianholovaty commented Jul 21, 2020 • edited by pr-preview bot Loading

clnoel commented Jul 21, 2020 • edited Loading

adrianholovaty commented Jul 21, 2020 • edited Loading

notator commented Dec 8, 2020

mdgood commented Dec 9, 2020 • edited Loading

notator commented Dec 9, 2020

adrianholovaty commented Dec 9, 2020

notator commented Dec 17, 2020 • edited Loading

clnoel commented Dec 17, 2020

ahankinson commented Dec 18, 2020

ahankinson commented Dec 18, 2020 • edited Loading

notator commented Dec 19, 2020

notator commented Dec 20, 2020 • edited Loading

ahankinson commented Dec 21, 2020 • edited Loading

notator commented Jan 5, 2021 • edited Loading

adrianholovaty commented Mar 7, 2024

adrianholovaty commented Jul 21, 2020 •

edited by pr-preview bot

Loading

clnoel commented Jul 21, 2020 •

edited

Loading

adrianholovaty commented Jul 21, 2020 •

edited

Loading

mdgood commented Dec 9, 2020 •

edited

Loading

notator commented Dec 17, 2020 •

edited

Loading

ahankinson commented Dec 18, 2020 •

edited

Loading

notator commented Dec 20, 2020 •

edited

Loading

ahankinson commented Dec 21, 2020 •

edited

Loading

notator commented Jan 5, 2021 •

edited

Loading