How to represent 'snippet' scores

[cecilios]

According to the classification in #68, snippet scores refer to examples and other small scores typically used in text books. Some have barlines but no time signature. There are no constrains on the content between bars (irregular measures). Usually very short scores and only one score part. E.g.:

I have doubs about how to represent the above score using current MNX draft.

1. Should I use a single measure element with intermediate barlines or six measure elements? As there are no time signature, I would say that the correct encoding would be to use only one measure element (one of the reasons for introducing the measure element was to capture the notion of measure; for no metric music the measure element should behave just as a container).

   Let's then use just one measure container (but the spec. does not prevent using six instead). Now it is necessary to add five intermediate barlines. But, as there are no measures I think it would be incorrect to use the implicit barline associated to the measure element; therefore, it would be better to use a measure element without barline and add six intermediate barlines. Alternatively, a different container element not implying 'measure' could be used. But as you can see there are again open options leading to different alternatives to represent the same score. And this is not an ideal solution if MNX is trying to define how things should be done and do not give too much options.

2. The barline element is not yet defined. But as one of the reasons for introducing the measure element was to capture the notion of measure, I would expect that the definition of the barline element could include restrictions on the allowed barline types inside a measure element, probably restricted just to dotted, dashed, tick and short barlines. Again, an alternative container element not implying 'measure' could be used without restrictions on the barline types it can include inside.

As you can see all this is speculation, but I have many doubts because current spec. is biased towards what I named 'normal scores' and gives no clues for dealing with the other score types. I don't feel comfortable reviewing and advancing on the 'standard' profile without studying in parallel the proposals for the other score types.

[clnoel]

@cecilios I will summarize here the debate we've been having in #68 that directly affects snippet scores, so rhat we can usefully continue.

I proposed that pieces without time signatures should include a time element with a "hidden" display attribute that preserves the correct visuals. Pieces like the sample above would need such an element almost every measure.

Your counter-proposal was to give measures a duration attribute, and to add a "none" option to the time element. Measure durations would only exist when that none option was used, and would in that case be required on each measure. That way the semantic information about measure durations could be easily accessible without going through the trouble of hiding an element.

Although I did not explicitly state it before, I would like to say here that I think that the meter or duration requirement is necessary only for some profiles, including the basic one, so that consuming programs can calculate duration. When we build a profile explicitly for snippets, I do not think we need any such thing, since consuming programs will be expecting pieces where the barlines serve more as conceptual divisions instead of time-based divisions.

[cecilios]

@clnoel Thanks for moving the discussion here. My proposal in #68 was not exactly what you summarized here but your summary is also acceptable to me. It was not a proposal for dealing with snippet scores but an alternative to the use of hidden time signatures in scores without time signature. Dealing with snippet scores requires more decisions, for example, your observation:

When we build a profile explicitly for snippets, I do not think we need any such thing, since consuming programs will be expecting pieces where the barlines serve more as conceptual divisions instead of time-based divisions.

Or the number of measure containers to use, as I observed in my first post.

[joeberkovitz]

Let me add a few observations to knit together points from other relevant conversations like #79.

• The example provided above by @cecilios is not the only kind of unmeasured music. It's a particularly well-behaved example in which we have ordinary measures with consistent meter across sequences, but no displayed time signature. But this is not always the case in measures lacking time signature and we should also consider cases like Couperin's unmeasured preludes.

• The idea of "urtext" vs. "well-behaved" as referenced in https://github.com/w3c/mnx/issues/79#issuecomment-375669407 may be useful here. In an urtext model, we don't need or want a <time> element, because the composer didn't provide one, and any attempt to encode a definite "duration" may be pointless (Couperin). But for scores like the one above, putting in a hidden time signature in a "well-behaved" profile is a great benefit: it allows the score to be handled in a reasonable manner in the ecosystem of CWMN notation editors and viewers.

• Even in truly unmeasured (and metrically inconsistent) music, something like a hidden measure boundary is very useful as a point where it's okay to introduce a system break in reflowed music.

[cecilios]

@joeberkovitz Good added points. The idea of "urtex" looks quite promising.

I would appreciate if you (or any informed group member) could explain current thoughts about the barline element. As the measure element provides the barline, I'm assuming that the barline element will be restricted to intermediate barlines not defining measure boundaries, such as dotted barlines. Clarifying the role and values of the barline element could be of great help to fit all the pieces together and find approaches to deal with the different types of scores. Some examples of scores with intermediate barlines could be also of help.

[clnoel]

@cecilios I see specifying a measure duration via a property to be equivalent conceptually to using a hidden time signature. They both give the measure a duration. The time signature method is slightly more verbose, and I can see how it could be considered a perversion of the original intent of the <time> element. I still favor the use of hidden time signatures in the well-behaved profile because that means that a basic consumer program only needs to be able to calculate measure duration one way.

@joeberkovitz Your point about needing barlines, even if they are hidden (there is a 'none' option in the current spec), to indicate potential system break points during reflow is a good one. However, that can possibly also be done using the barline element. I, too, am interested in how that element is envisioned.

P.S. @cecilios I'm sorry I didn't quite get your counter-proposal quite right. I'm glad it was close enough.

[joeberkovitz]

The present-day barline element in MusicXML can function as either an intermediate or an end-of-measure barline, depending on its position. In MNX, however, there is a distinction that gets rid of this ambiguity.

The barline element is always a direction to show a barline within a measure, and it does not define a measure boundary.

The barline attribute of a measure, in contrast, is always a description of a measure boundary.

[cecilios]

@clnoel Your interpretation of my proposal is better than my proposal: the 'time' element is always mandatory (this avoid problems) and explicitly states that there is no time signature.

I still favor the use of hidden time signatures in the well-behaved profile because that means that a basic consumer program only needs to be able to calculate measure duration one way.

By "hidden time signatures" I understand <time signature='none' />. If this is also your understanding, I agree with your point. Having only one way to calculate measure duration is good, although it increases the complexity for dealing with snippets scores, such as the one in my example, as it forces to include a time element on each measure. But, to me, the balance 'consumer app. complexity' vs. 'some files verbosity' must go on reducing consumer app. complexity. So I'm ok with you proposal.

@joeberkovitz Thanks for the clarifications. If the the barline element does not define a measure boundary, should their possible values be restricted to intermediate barlines (dotted barlines) or would it be possible to use 'regular' barlines? Are there use cases in which regular barlines do not define a measure boundary? (excuse my lack of knowledge, I'm not an academically trained musician)

[joeberkovitz]

@cecilios In MNX, "hidden time signature" does not mean <time signature="none"/>, it means <time signature="m/n" style="display: none;"/>. Note that this situation frequently occurs not only in so-called "snippets", but in full-blown compositions that fail to include written time signature changes (of which there are many -- antique Christmas carols and French chansons are good examples). Treating these situations the same way has a big payoff.

Also, barline element is not restricted to appear as a dotted barline. For flexibility, it needs to look any way the composer wants it to look. So the appearance choices would be the same as for a regular measure boundary.

[cecilios]

@joeberkovitz I'm contrary to assigning semantic values to style attributes.

I can understand and accept the use <time signature="m/n" style="display: none;"/> in cases such as the one you describe, as having the time signature displayed or hidden does not change the fact that there is a time signature change and the new provided value is valid. Any consumer app. wishing to determine the applicable time signature will just need to watch the 'signature' attribute and can safely ignore any applicable style.

But the case we are discussing, snippet scores without time signature, is not equivalent. You are proposing to encode an arbitrary time signature to match the measure duration and to hide it. The 'right' encoding (parallel to previous case) would be <time signature="none" style="display: none;" measure="m*n"/>. In this last example, the style is irrelevant and the time element properly encodes the semantic.

Take into account that deriving semantic values from style properties can be complex, as styles are inherited from parent elements, classes, etc. It is not enough to look for an 'style="display: none;"' property in the time element. And it is not a clean way of encoding semantic values.

[cecilios]

I forget to add that 'signature="none"' automatically implies displaying nothing and, so, there is no need for 'style="display: none;"'

[joeberkovitz]

Your suggestion makes life more complicated for implementors, because now applications need to look for a duration in two different places. So far I have disagreed that the omission of the time signature is "semantic" -- but that point is worth discussing further. But note that if the lack of visibility were indeed semantic, that would not require two alternative ways of representing the measure's duration. One could simply make visibility a semantic flag that is true or false.

It's worth asking what behavior we would expect to be different in any application for a signature of "none" that has a de facto m/n time signature, vs. a hidden m/n time signature. I can't think of any advantage to these either looking different, or being editable in different ways.

[mdgood]

I think we really do need a "none" time signature that is different than a hidden time signature. One use case would be a musicology analysis trying to determine the amount of unmeasured music in a particular corpus. Another would be to represent scores that explicit indicate the absence of a time signature with a symbol. SMuFL has two of these symbols, timeSigX and timeSigOpenPenderecki, in the time signatures range.

[cecilios]

@joeberkovitz I'm not sure if we are using the same context information. I'm specifically referring to the snippets case without time signature. I understand, according to the conversation between @clnoel and me, that it would be better not to introduce a 'duration' attribute in measures but to encode a time element on each measure, and to use its 'measure' attribute for encoding the duration. Therefore, if my understanding of the spec, is right, what I'm doing is to follow the standard procedure for determining measure duration and requesting a special value signature="none" for explicitly saying that there is no time signature instead of having to infer that by assuming that from a valid signature with hidden visibility. In this last case, the valid uses of hidden time signature could be misinterpreted as no time signature.

[joeberkovitz]

@mdgood @cecilios In both of these cases it seems that we have a different use case -- one that would be answered by relaxing the profile in favor of an urtext interpretation. In these cases, "none" perhaps makes sense -- but omitting <time> altogether might make even more sense....

[cecilios]

@joeberkovitz If the barline element is not restricted, this might open the door to alternative encodings of the same score. And this is not good. E.g., for the snippet score of my example, there would be the choice of using only one measure element with several barlines, six measure elements or any intermediate number of measures with barlines, without violating any syntactic and semantic rule.

[cecilios]

@joeberkovitz Perhaps the intermediate barline appearance should be a visual style rather than a semantic value. The value should always be that of an intermediate barline, but its appearance could be changed via style values.

[mdgood]

@joeberkovitz I don't think omitting a time signature can handle the case with open time signatures with explicit SMuFL symbols. I realize this isn't a snippet score use case, but the time signature feature discussion crosses between stories.

[joeberkovitz]

@cecilios These alternative encodings will not have the same behavior, so they represent a legitimate choice that is important to expose to engravers. A single measure with intermediate barlines will not be broken across systems by default, while separate measures will be considered as discrete chunks that can be separated by system breaks.

@mdgood I get it. I think we need a separate issue on the true "none" case which cites some examples.

[cecilios]

@joeberkovitz Ok. I got the idea about barlines. The spec. will then clearly say that the barline element will be always considered as an intermediate barline irrespective of its value and, so, it does not represent a valid place, as first choice, to break the system.

[clnoel]

@joeberkovitz Consuming apps already have to take the <time> element's measure value into account in order to handle pick-up measures, so using it with signature='none' does not impose more complexity. I don't know the use cases for the open time signatures, so I look forward to watching that discussion. I would like to point out in passing that I don't see a way to use the 'cut time' and 'common time' symbols either.

@cecilios Exactly. In your snippet score example, some of those bsrlines could be measure boundaries, and some could be intermediate, depending on how the referencing text uses it. In isolation, I would default to assuming a barline ends a measure even in a snippet score.

[cecilios]

@clnoel Thanks for your comments. My impression is that it is going to be difficult to continue the conversation until more information -- i.e. the urtex interpretation, the true time signature 'none', or the barline element -- is provided by a draft spec. So, for now no more comments on my part on these issues.

[joeberkovitz]

Thanks @clnoel, I had a very bad case of tunnel vision there, forgetting about pickups. Everyone (including the author :-) also forgot about the existing <time measure="..."/> attribute, which already provides an explicit duration for the measure indpendent of what was notated in any time signature. That was there precisely to handle pickup measures.

I think this does take us back to @cecilios proposal of something like a none time signature with the measure attribute providing the length of the measure. (It's not called duration, at least not yet, but perhaps that is a better name.) Perhaps it's worth asking, which of the following is better: <time signature="none" measure="6/4"/> or simply <time measure="6/4"/>?

Cut/common time symbols are now the new issue #94.

[clnoel]

@joeberkovitz The measure attribute as written is supposed to override the time signature for the current measure. Perhaps current-measure or current-measure-duration is a better name, but I dislike duration by itself, since the <time> element itself doesn't have a duration. I'm okay with skipping the signature attribute, except on the first measure, which should explicitly establish the default signature.

[cecilios]

@joeberkovitz It depends on objectives to achieve. Does time implies a time signature definition/change? Probably yes. Then, requesting signature="none" on every measure of the snippet score could be bad, as would imply a time signature change on every measure and that's not true. The proposal from @clnoel is better, by adding the following rationale:

Lets define that

• time signature=.. does imply a signature definition/change. Therefore signature="none" will be required for first measure in snippet score.
• time without signature attribute just modifies current measure duration but do not introduce a new time signature. Therefore signature is not required in all other measures in snippet score.

[cecilios]

The same rationale is applicable to regular scores, in the final measure (incomplete) due to an anacruxis start. Last measure will require just <time measure="xxx" />.

[cecilios]

What if the 'measure' attribute is removed from the time element and placed in the measure element? Seems cleaner to me.

[clnoel]

The problem I have with moving the measure attribute into the <measure> element (and calling it something else, presumably) is that the <time> element is a child of the <measure> element, and it doesn't make sense to me to override the duration of the measure (as one of the measure's attributes) before you define the default in the first place.

From a processing standpoint, it might make for shorter files to not have to have a <time> element for every measure attribute needed, but I don't think it "cleaner" because if it is part of the <time> element then all durational calculations will happen during the processing of a single element, and not be spread across elements.

[joeberkovitz]

@cecilios Yes, I think it does make sense to allow <time measure="..."/> with no signature attribute, in which case the signature currently in effect simply continues. (We would have to define a default signature, probably "None").

Note that the measure attribute is designed to act as a temporary override: it does not carry over: for an anacrusis you'd have <time signature="4/4" measure="1/8"/>, and then the next measure would be a regular 4/4 measure (with no additional <time> element required). The spec should be modified to explain this.

That behavior means that if you make the signature "None", then you will need a <time measure="..."> element for every measure in the score. Which is probably not an issue: if there's no time signature in effect, every measure needs to state its duration.

(I'm in agreement with @clnoel that brevity is not as important as keeping all the metrical information together in the <time> element. Shorter is not always better; ease of processing and coherence are usually more important.)

[cecilios]

@clnoel Imagine a colour attribute for overriding a given measure default background colour. Would you place it in the measure element or in a contained time signature element? For me, it will be conceptually cleaner to place it in the measure. But from other points of view the situation could be different. Besides academic discussions, my suggestion has some practical benefits: no longer need to define a signature='none' value (at least for snippet scores); also for snippets scores, no need to include a 'time' element on each measure. Moreover, placing the attribute in the suggested place would not require additional explanations stating that it acts as a temporary override. From a processing viewpoint, both options are equivalent: the steps to determine the measure duration are more or less the same and in both options in some cases you can not determine the duration until having checked if there is a 'time' child defined and having processed it. Anyway, it was just a suggestion not a request.

@joeberkovitz I'm wondering what did I write that made you infer that I had misunderstood the scope of the measure attribute. But anyway, thank you for the explanation.

[joeberkovitz]

@cecilios it wasn’t anything you said, it’s just that the spec itself doesn’t seem clear on the scope.

[adrianholovaty]

Marking this as closed, for the sake of cleaning up our issue database. This is very outdated — it deals with the older XML version of MNX.