textual dynamics can be more general

[jsutdolph]

in 5.2.9.2 you define all the dynamics that you think people will need, but why limit it? Why not either a) use a set of minimal elements which can be combined eg 'm', 'p', 'f', 's', 'z', 'r' or b) allow general text

[joeberkovitz]

Can you provide use cases that illustrate what we're missing, by sticking with the MusicXML set of predefined dynamics? Examples from the literature, or concrete scenarios, would both be helpful.

I think the syntax of dynamics could theoretically be opened up, bearing in mind that the SMuFL font system does only offer a limited palette of minimal elements and if we want things to look like dynamics, we'd have to stick to that subset of characters. (Note that MNX <expression> elements do support general text.) In that case, MNX would permit the type to be any string that combines these allowed characters, and we'd spec the performance interpretation to be defined only in the traditionally-understood cases (and null otherwise).

So it's doable, but without grounding this in some real use cases it's going to be hard to discuss it meaningfully... how much will this open-ended buy us? (Bearing in mind that it implies we will give up some degree of validity checking.)

[mdgood]

MusicXML has two ways to do this: 1) allowing a sequence of dynamics elements and 2) providing an other-dynamics element as an escape. These are used for cases like sfzpp and p - f where a single dynamic indication does not match a single SMuFL symbol. (The latter can be used in repeated sections.)

[jsutdolph]

@joeberkovitz In my experience whatever set you define (eg the MusicXML set) there will be some that are not included. Why should the composer (or OMR engine) not be free to put any sequence of smfpzrn? I have definitely come across some that aren't in the list, but I'm sorry I cannot remember what they were. @mdgood. Yes the MusicXML way to combine these usually works (SeeScore uses this technique for the non-standard sequences), but also I think there are some plausible possibilities that cannot be synthesised from these puzzle pieces (though I cannot think of one at the moment). The other-dynamics element is not ideal as it can be interpreted in different ways by different applications. Nowhere does the spec say how it is rendered. However it would be so much simpler just to provide the possibility of specifying any string containing these characters. Why do we need a standard set at all? It is not unusual for an app to output some illegal sequence in MusicXML and then those of us using validating XML parsers cannot load the file. This is really annoying!

[joeberkovitz]

I was not arguing against loosening this area up. (In fact, Noteflight allows any string to be entered for dynamics.)

But I do think it would be good to support this argument with some musical examples from the literature, instead of just arguing from a philosophical point of view (and I personally agree with the philosophy, but not everyone else does).

[shoogle]

I think there are acually two separate issues here:

1. Dynamics that can be split into more basic types (e.g. fp).
2. Dynamics that contain arbitrary text (e.g. "sempre p").

I created #168 to deal with the former.