Actions

[notator]

This issue continues the discussion in Pull Request #190 (which I think should now be rejected and closed).

Summary of the discussion in #190:

• Custom HTML entity strings can be defined in MNX. (see @ahankinson's https://github.com/w3c/mnx/pull/190#issuecomment-748930959) For example: <!ENTITY segno CDATA "&#x1D10B;" > at the top of a file defines the &segno; entity string to mean the segno character. In future, I'll be using such entity strings, without further comment, as if this has been done.
• References to local IDs should begin with a '#' character (see @ahankinson's https://github.com/w3c/mnx/pull/190#issuecomment-748117620). Edit 29.08.2021: I've changed my mind on this. References to local IDs should not begin with a '#' character. See https://github.com/w3c/mnx/issues/57#issuecomment-896625535.
• There is an issue with multi-line text (see https://github.com/w3c/mnx/pull/190#issuecomment-748453764 and https://github.com/w3c/mnx/pull/190#issuecomment-748589825). I'm proposing the use of two new elements: <text> and <textBlock>, both of which need defining more precisely. The <text> element would replace the <instruction> element in the Draft Spec.
• Apropos https://github.com/w3c/mnx/pull/190#issuecomment-741691052 about mid-measure repeats: MusicXML's treatment of repeat signs as barline types means that it has to use a hack to implement mid-measure repeats. Both of its available codings lead to confusion about what is and is not a measure, and consequently to confusion about the measure numbers, so they are clearly inferior to not treating repeat signs as barlines in the first place. I therefore disagree with @adrianholovaty 's https://github.com/w3c/mnx/pull/190#issuecomment-741703318 that "no special markup would be needed for this case". This example still has to be added to MNX by Example, and should, as always, contain both the MusicXML and the MNX code.
• I'm proposing that a <switch> element be defined, containing an ordered list of actions to be taken when the <switch> is encountered during a performance. Note that <switch> elements are not rendered graphically, and can safely be ignored by non-performing applications. (I've always been looking for a better name for this element, and am going to rename it again below. Names are important.) My final comment in #190 lists the (currently proposed) possible actions as
  • goto somewhere
  • continue
  • pause

  • stop.

Further thoughts:

First, I'd like to rename <switch> (aka <jump>) to <actions>. This makes the element's type more obvious and precise since, in addition to having a location in the score, it contains an ordered list of action elements, each of which is a non-printing, imperative verb that has to be executed at a particular time.

Begin Edit 9 Jan., 2021 I'd also like to define a new <action> (singular) element. The two definitions look something like this:

1. The <actions> element contains an ordered list of two or more action elements that define a stack of actions. Each time the <actions> element is invoked, the action on the top of the stack is executed and then popped off the stack. If the stack is empty, the <actions> element does nothing.
2. The <action> element contains exactly one action element that is executed each time the <action> element is invoked.

End Edit

Clearly differentiating between graphic and temporal information leads to a much simpler and considerably more powerful way to code repeats and jumps, so the current <repeat> and <ending> elements, and all printed texts (such as "dal Segno", "&segno;", "Da capo als segno" etc.) have to be considered to be purely graphical objects.

Of course, it may be possible to infer a behaviour from the graphics, but the following problems arise:

• A performing application may be unable to interpret the graphics. This will, for example, be the case when dealing with unknown accidentals (see the discussion with @cmloegcmluin in #184)
• The graphics may mean different things at different times. This is the case when dealing with 1st, 2nd, 3rd time etc repeat measures, or when a simple repeat is supposed to be played louder, slower etc than the first time through.

As will be seen in the accel. example below, its easy to define specialised actions for purposes other than repeats and jumps. If there is consensus that I'm on the right track here, we could well be doing that over the next few weeks, but my primary objective is to create a revision of the current MNX by Example examples and the Draft Spec that can be presented as a Pull Request before the next co-chair meeting (19th January).

---

Examples:

The Repeat examples in MNX by Example are still okay, but should be considered to contain only graphic information. As discussed in #190, the Jump examples in MNX by Example need revising. The Jump examples in #190 are, I think, more or less okay, but the <jump> elements there need to be renamed <actions>.

The following examples are only supposed to demonstrate the principle behind using <actions> and <action> elements. Any new actions they may use are placeholders, not precise proposals. Feedback would, of course, be very welcome!

The simplest one-time repeat would be coded, using an <actions> element, like this:

<mnx>
    <global>
        <measure>
            <directions>
                <time signature="4/4"/>
                <repeat id="startRepeat1" type="start"/>
                <repeat type="end"/>
                <actions location="4/4">
                    <goto target="#startRepeat1" />
                    <stop />
                </actions >
            </directions>
        </measure>
    </global>
    ...
</mnx>

Notes:

• The <stop /> is compulsory because an <actions> element must contain at least two action elements. A <continue /> would be used for a repeat that is not at the end of the score.
• using an <action> element here would result an endless loop.

              <action location="4/4">
                  <goto target="#startRepeat1" />
              </action >

A varied repeat:

<mnx>
    <global>
        <measure>
            <directions>
                <time signature="4/4"/>
                <repeat id="startRepeat1" type="start"/>
                <text location="0" string="&forte;, 2nd time &piano;" orient="down" />
                <actions location="0">
                    <continue>
                    <masterVolume value="50%" />
                </actions >
                <repeat type="end"/>
                <actions location="4/4">
                    <goto target="#startRepeat1" />
                    <stop />
                </actions >
            </directions>
        </measure>
    </global>
    ...
</mnx>

An accel would be coded using an <action> (singular) element:

<mnx>
    <global>
        <measure>
            <directions>
                <time signature="4/4"/>
                <text location="1/8" string="accel." orient="up" >
                    <extender duration="7/8" class="accelDashes" />
                </text >
                <action location="1/8" >
                    <speedChange factor="200%" type="linear" duration="7/8" />
                </action >
            </directions>
        </measure>
    </global>
    ...
</mnx>

This is the usual way to code actions that happen once. But note that if this example was contained in a repeat, the <speedChange> would be executed every time the <action> was invoked, and the performance would continue to accelerate.

---

Issues:

Some <text> elements, such as accel., don't need to be printed in every part in a score, but would be needed when extracting parts. Possibly, in a score containing many parts, the <text> could be defined separately in each part that requires it, but the rules governing global <text> still need to be worked out. This may also involve being more precise about our use of global and local CSS. Note the different behaviour of <repeat> and <ending> elements. These must be printed in all <part>s, both in the full score and in the individual part-booklets, so they don't need <part>-specific CSS.

Each of the available action types (=elements) needs to define precisely how and where it can/should be coded. For example, a <speedChange> can only be global, but <part>s should probably be allowed to have individual changes of dynamic: In a repeated measure having two parts, one part could have "&forte;, 2nd time &piano;", while the other has "&piano;, 2nd time &forte;".

Comment & suggestions welcome.

[bhamblok]

I'd like to comment on your proposal of the <text>-element. Wouldn't it be nicer if we put the value of the "string"-attribute simply as content of the element?

<text location="0" orient="down">&forte;, 2nd time &piano;</text>

and

<text location="1/8" orient="up" >
    accel.
    <extender duration="7/8" class="accelDashes" />
</text >

[notator]

@bhamblok Thanks for the feedback! :-). I'm in the process of moving the debate about text into its own issue, so will reply to you there when I post it. Should be ready soon.

I've now updated my original posting to this issue (Actions) to include a proposal for a new <action> (singular) element.

[notator]

The <action> element is redundant. See https://github.com/w3c/mnx/issues/217#issuecomment-761548580

[notator]

I'd like to define the way the <actions> element works more precisely, and thereby make a small change:

1. The contained list of actions defines a stack of actions.
2. Each time the actions element is reached during a performance, the action at the top of the stack is performed, and then popped of the top of the stack.
3. When the stack is empty, no action is performed.

This means that

• the <stop /> is unnecessary in https://github.com/w3c/mnx/issues/216#issue-784966091 since the action is at the end of the file
• it is always unnecessary (but harmless) to define a <continue> action at the bottom of the stack.

Summary: I think the following actions are basic

• <goto target=... />
• <continue />
• <pause />
• <stop />

I also think that all action elements should always be enclosed in an <actions> element, even when there is only one of them. That means that graphics-only applications can ignore them more easily, and that #221, #220 and #218 need to be changed accordingly. (Now doing that.)

After proper discussion, further actions are likely to be defined in future (for example something like <speedChange> in the accel. example above.)

[adrianholovaty]

Closing an outdated issue.