@dots missing on mRest #429
Comments
|
Centered full-measure rests are not supposed to have augmentation dots. |
|
meaning |
Yes, especially in 3/8:
Putting a dot on the whole-measure centered rests ( An exception would be for meters equal or greater than 8/4, where a whole-measure rests looks stupid if using a whole rest, so a breve rest should be used. And by extension meters equal or greater than 16/4 should use a long rest, and equal or greater than 32/4 should use a maxima rest (and 64/4 and higher should use a double maxima rest, but now things are getting silly).
So actually the real reason for the lack of This is contrary to Here is an example of music in 11/8:
Notice that it is impossible to have a single note representing a sustained note filling a measure in 11/8, so it must be split into two notes added together with a tie. Similarly there is no single rest which represents 11 eighths notes, so the MEI test data: <?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="http://music-encoding.org/schema/3.0.0/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="http://music-encoding.org/schema/3.0.0/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="3.0.0">
<meiHead>
<fileDesc>
<titleStmt>
<title />
</titleStmt>
<pubStmt />
</fileDesc>
<encodingDesc>
<appInfo>
<application isodate="2017-04-24T11:10:57" version="0.9.14-dev-98874c6">
<name>Verovio</name>
<p>Transcoded from Humdrum</p>
</application>
</appInfo>
</encodingDesc>
<workDesc>
<work>
<titleStmt>
<title />
</titleStmt>
</work>
</workDesc>
</meiHead>
<music>
<body>
<mdiv>
<score>
<scoreDef xml:id="scoredef-0000001194634597">
<staffGrp xml:id="staffgrp-0000001503258451">
<staffDef xml:id="staffdef-0000000102767551" n="1" clef.shape="G" clef.line="2" meter.count="11" meter.unit="8" lines="5" />
</staffGrp>
</scoreDef>
<section xml:id="section-0000001133282998">
<measure xml:id="measure-L3" n="1" type="m-1">
<staff xml:id="staff-L3F1N1" n="1">
<layer xml:id="layer-L3F1N1" n="1">
<note xml:id="note-L4F1" type="qon-0 qoff-4 pname-c acc-n oct-4 b40c-2 b12c-0 tie-start" dur="1" oct="4" pname="c">
<accid xml:id="accid-L4F1" accid.ges="n" />
</note>
<note xml:id="note-L5F1" type="qon-4 qoff-11_2 pname-c acc-n oct-4 b40c-2 b12c-0 tie-stop" dots="1" dur="4" oct="4" pname="c">
<accid xml:id="accid-L5F1" accid.ges="n" />
</note>
</layer>
</staff>
<tie xml:id="tie-L4F1-L5F1" startid="#note-L4F1" endid="#note-L5F1" />
</measure>
<measure xml:id="measure-L6" n="2" type="m-2">
<staff xml:id="staff-L6F1N1" n="1">
<layer xml:id="layer-L6F1N1" n="1">
<mRest xml:id="mrest-0000001150793255" />
</layer>
</staff>
</measure>
<measure xml:id="measure-L8" n="3" right="end" type="m-3">
<staff xml:id="staff-L8F1N1" n="1">
<layer xml:id="layer-L8F1N1" n="1">
<note xml:id="note-L9F1" type="qon-11 qoff-15 pname-c acc-n oct-4 b40c-2 b12c-0 tie-start" dur="1" oct="4" pname="c">
<accid xml:id="accid-L9F1" accid.ges="n" />
</note>
<note xml:id="note-L10F1" type="qon-15 qoff-33_2 pname-c acc-n oct-4 b40c-2 b12c-0 tie-stop" dots="1" dur="4" oct="4" pname="c">
<accid xml:id="accid-L10F1" accid.ges="n" />
</note>
</layer>
</staff>
<tie xml:id="tie-L9F1-L10F1" startid="#note-L9F1" endid="#note-L10F1" />
</measure>
</section>
</score>
</mdiv>
</body>
</music>
</mei> |
Precisely,
Again, spot on (except for the invisible rest part, |
|
I guess @rettinghaus is coming from examples typical for Bach, where he writes a whole rest in one measure, and then an augmentation dot in the following. While this is not the way we would handle it nowadays, it's perfectly valid for CMN of his period, and, luckily, MEI allows to encode that in a much better way than using |
That is a different situation, is it not? In 4/4 that would indicate a rest with 6 quarter notes duration, but the dotted part of the duration is in the next measure. And that sort of notation was also applied to notes:
The whole note rest still gets its duration from the meter, and the augmentation dot adds half of whatever that is. |
|
It's not that I want to have a (visual) dot on mRest. I just wanted to point out the ambiguity of |
|
@rettinghaus, I think we are on the same page then. Yes, |
|
That is a funny one with a barline splitting a notehead. A general problem is what is meant by CMN, with "C" meaning common? Is splitting the note in half by a barline something a publisher would do, or is it something that is a shorthand for writing the score out by hand (save time to not write out a separate note and draw a tie)? I wonder what would happen if there were a quarter note in the bottom staff on the last beat of the first measure? Would that cause the notation of the measure-split note to change? It would have to be moved to the left to align with the quarter note... And would the performance parts do the same thing? Barlines had just been invented, and people were experimenting with their syntax, so this is a now extinct transitional species. Are there any tied notes in the manuscript? I presume that tied notes had been invented by the time this was written, but it would be interesting if not. Another thing would be the flat in the bottom key signature. Notice that it splits the clef symbol in half. Should that be encoded? Here is how I would do it in SCORE:
This turned out to be moderately easy. To split the notehead by the barline, I added a horizontal offset to the notehead to place it on the barline. The dot is represented by a note object that has no stem or notehead, just an augmentation dot and a duration of a quarter note. In theory I could have attached the dot to the previous note, but in SCORE there is a maximum dot displacement which is slightly less than I wanted, so I had to detach it from the owning note. The main complication is that you cannot do LJ (line-up and justify for horizontal spacing) with the barline going through a note, even if it has an explicit horizontal offset, since SCORE will force them to not collide. However, I can make the barline only one staff high, then do LJ, and then make it 2 staves high again to get the proper horizontal spacing:
So the main fiddly part is to temporarily change the barline height. Here is encoding the stem directions and lengths of the original:
In Humdrum I would encode it with a modern syntax of splitting the notes across the barline with ties. For analyses based on semantics I would not care about the syntax of the notes in this configuration, but I have dealt with a similar situation in JRP: http://josquin.stanford.edu/cgi-bin/jrp?a=notationEditText&f=Jos0402a
In this case the long in the tenor part is twice as long as those of the other parts. This is a terminal long, and such a long can last for several measures. The note is supposed to be held until everyone comes to their final notes, so it functions similar to a fermata in modern notation while the other parts are finishing. Here is the Humdrum score at that point in the music: http://josquin.stanford.edu/cgi-bin/jrp?a=humdrum&f=Jos0402a I add the character "l" to notes which should be displayed as long notes. This in turn causes all of the attached tied notes (and ties) of the secondary tied notes to be hidden in the rendering of the notation. For the current example, I would probably do it like this in Humdrum: The "i" and the "N" would function similar to "l" in the previous example to instruct the renderer to use a non-modern syntax for those notes. An advantage of this system is that it is renderable in verovio with my current converter and verovio's current rendering capability:
My converter is also set up to deal with such a representation in a useful way with verovio, where I can highlight the notes in the score that are an exception to current CMN:
I add the text "marked note" to the user signifier definitions, with the default rendering color being red, and then one category is given a green color. For encoding in MEI, I leave that up to |
|
What if we replaced all invocations of |
|
As this is a pretty huge step, I didn't dare to suggest something like this by myself. But merging I'm just not sure if dropping |
|
@rettinghaus: I understand your trepidation, but But, one could still end up with markup like -- which is confusing at first, especially for those already familiar with MEI. (After the movement of |
|
Another thing to consider is how to easily control the number of dots that events are allowed to have. Right now, with a separate |
|
To me, all this feels like we're trying to squeeze too many details into too little room. Also, the proposed change of dur _is_ quite dramatic, I would say. I'm not happy to follow based on the set of arguments on the table right now, even though I'm aware that we have too many different types of durations…
… Am 25.04.2017 um 21:42 schrieb pe-ro ***@***.***>:
@rettinghaus: I understand your trepidation, but @dots isn't analytical domain material, in my opinion. It would be confusing to find it in MEI.analytical. If we don't want to drop it entirely just yet, then putting it in the visual domain makes the most sense to me.
But, one could still end up with markup like --
<note dur="4.." dots="1"/>
which is confusing at first, especially for those already familiar with MEI. (After the movement of @dots from the logical to the visual domain, this would indicate that the logical duration is a double-dotted quarter note, but that only 1 dot is actually displayed.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Having too many different types of duration is a major problem. I think this fixes it nicely. The change is not as big a shift as one might think. It still leaves logical and visual duration coupled in |
|
This should, in fact, make hand coding easier/better. |
|
It feels like a reminiscence to the good old ASCII days, where one would have to parse different information out of a combined string. I agree having different types of duration is a major problem. It's just I wouldn't start to change on this end…
… Am 25.04.2017 um 21:51 schrieb pe-ro ***@***.***>:
Having too many different types of duration is a major problem. I think this fixes it nicely.
The change is not as big a shift as one might think. It still leaves logical and visual duration coupled in @Dur, it just changes the syntax; that is, collapses @Dur + @dots into @Dur alone.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Where would you like to change it? |
|
Generally, I agree that attribute value parsing isn't good, but if it makes things simpler (i.e., more easy to understand), then why not? |
|
I don't know right now, and would have to have a deeper look into the issue before being able to give a qualified response. It's just that the duration on notes seems to be the most common one. If there are conflicting definitions, then I would look if we couldn't change the ones that are less frequently used: If there's a solution that breaks only 30% of all existing encodings, that seems preferable over one that breaks 100%, at least from my naive perspective ;-)
… Am 25.04.2017 um 21:55 schrieb pe-ro ***@***.***>:
Where would you like to change it?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
We've been down the road of breaking everything into multiple attribute values. The next stage of development is to look for those places where we can reduce the number of attributes even if the result is more complex values. |
|
Breaking existing markup isn't a big deal if we provide a conversion mechanism. |
|
I think all I'm saying is that we should slow down on this a bit, think it over a couple of days, and be sure about the consequences. That change is drastic, and it's not only about breaking compatibility of the encodings, it's also likely to break every existing MEI application (MerMEId being the only exception I can think of…). That seems a lot compared to an uneasiness with the current situation, which might perhaps be addressed by better documentation first. I just don't want to rush into an adventure as big as this one too easily.
… Am 25.04.2017 um 21:59 schrieb pe-ro ***@***.***>:
We've been down the road of breaking everything into multiple attribute values. The next stage of development is to look for those places where we can reduce the number of attributes even if the result is more complex values.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
The conversion mechanism is to add the number of dot characters provided in becomes |
|
4.0 is already going to break existing applications. You're right, there's no rush to do this. But, it will hold up getting 4.0 out the door and therefore MEI Basic, because I don't want to release 4.0 without having Basic mostly done. |
|
Then I would table it until we talk about 5.0. Honestly, let's avoid to rush on this. Everyone survived until today with the current situation, and I'm sure no one will die immediately
if we keep it some more months. It's something that should be discussed in person, perhaps at the Hack Day during MEC in Tours…
… Am 25.04.2017 um 22:06 schrieb pe-ro ***@***.***>:
4.0 is already going to break existing applications.
You're right, there's no rush to do this. But, it will hold up getting 4.0 out the door and therefore MEI Basic, because I don't want to release 4.0 without having Basic mostly done.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
At least we should proceed with the suggestions in #429 (comment). |
|
agreed |
|
Please don't change something like this without adequate time for community notice and feedback. I agree that this should wait until 5.0 at the earliest. |
|
Conversion mechanisms are OK for converting data, but breaking changes also break software, and there is no conversion mechanism for that. |
|
All the more reason to put as many breaking changes as possible into a single version. Parceling them out can feel like death by a thousand cuts. But, if you want to wait, we'll wait. |
|
We need to give people time to adjust to changes, and understand the reasons for making them. MEI doesn't have the luxury of not bringing lots of people along for the ride now, and making changes to fundamental components, like the representation of durations, is something we need to communicate before, during, and after the change. Do we really gain that much more by changing this? What sorts of operations does this affect? I know it will affect our ability to do math directly on number-like duration values, for one, which seems like a pretty significant loss of functionality. I'm with Johannes, that this feels very un-MEI and hearkens back to the string-parsing days. That's fine, but it's not MEI. The "." is really only a useful character because of its shape; an ASCII period is not an indicator that half the preceding value should be added to it. |
|
http://music-encoding.org/documentation/2.1.1/att.duration.additive
I would avoid using the word irrational since musical rhythms are mathematically called rational numbers (but that does not stop musicians from using the term irrational for rational numbers :-). An irrational rhythm would be pi-uplets or the square-root-of-three-uplets.
It does not seem too large of a change due to this sentence: currently when there are dots in What about I have come across a few cases of visual dots not matching rhythmic dots in C.P.E. Bach digital scores (but I would have to search my notes for where they are). But they are very rare (other than for mensural music where augmentation dots are usually invisible :-) So for this example:
The additive duration of the rest would be something like: or It is a bit of a bother that there are innumerable ways to represent an additive rhythm... In humdrum I describe that rhythm as the actual sum You could instead modify additive duration representation to represent an actual sum rather than a list of space separated durations with augmentation dots (space-delimited values are way too complex for some programmers who cannot parse strings). The addition has to be done on the inverse of the rhythms (i.e., as actual durations): Augmentation dots could then be removed from such a representation since it is purely logical and visual dots are not needed, although you will have to decide if it should allow non-power-of-two rhythmic values before dots are applied . Also breves would be 1%2 (2/1 whole notes), longs are 1%4 (4 whole notes), and maximas are 1%8 (8 whole notes), at least in modern/imperfect mensurations. "4." means 3/8ths of a whole note, so in Humdrum **recip representation (recip = reciprocal), this can be also represented by "8%3" without the dot. Interlude: In terms of rhythmic reforms, I would be most interested in phasing out variable-unit
That is a good point (as in decimal point). Computer programmers will first think it is a decimal point and get confused. Especially since some durational units such as
The good news is that SCORE is purely numeric. Here is the 11/8 meter represented in SCORE numeric form: All dots in the above data are decimal points. This example also reminds me that SCORE has an additive duration representation for text-based user input. It is basically the spaced rhythms system of MEI additive-durations without the spaces or the dots). All rhythmic values can be represented by numbers, but the main power-of-two ones have letter abbreviations, and these letter abbreviations can be glued together to form an additive duration: So Likewse, MEI additive durations could exclude dots by expanding them:
|
|
I like the idea of expanding the dots in an additive duration --
The idea behind making all durations adhere to the additive datatype was to be able to force Re: qtstamps -- Although it's not called The ultimate goal is to resolve the issues MEI has regarding duration sooner rather than later by employing |
I don't see this as related to gestural vs. logical. Here is an illustration of the problem:
In both cases the duration of each measure is the same: (3 quarter notes = 6 eighth notes), and rhythmically in both cases there is a fermata on each eighth note, but the <fermata staff="1" tstamp="1" place="above" />
<fermata staff="1" tstamp="1.5" place="above" />
<fermata staff="1" tstamp="2" place="above" />
<fermata staff="1" tstamp="2.5" place="above" />
<fermata staff="1" tstamp="3" place="above" />
<fermata staff="1" tstamp="3.5" place="above" />versus: <fermata staff="1" tstamp="1" place="above" />
<fermata staff="1" tstamp="2" place="above" />
<fermata staff="1" tstamp="3" place="above" />
<fermata staff="1" tstamp="4" place="above" />
<fermata staff="1" tstamp="5" place="above" />
<fermata staff="1" tstamp="6" place="above" />What I am saying is that it seems more logical to have the same time unit for the stamps across all meters (or cases where there are no meters or compound meters): <fermata staff="1" qstamp="1" place="above" />
<fermata staff="1" qstamp="1.5" place="above" />
<fermata staff="1" qstamp="2" place="above" />
<fermata staff="1" qstamp="2.5" place="above" />
<fermata staff="1" qstamp="3" place="above" />
<fermata staff="1" qstamp="3.5" place="above" />versus: <fermata staff="1" qstamp="1" place="above" />
<fermata staff="1" qstamp="1.5" place="above" />
<fermata staff="1" qstamp="2" place="above" />
<fermata staff="1" qstamp="2.5" place="above" />
<fermata staff="1" qstamp="3" place="above" />
<fermata staff="1" qstamp="3.5" place="above" />Full measure 1: <scoreDef>
<staffGrp>
<staffDef n="1" clef.shape="G" clef.line="2" meter.count="3" meter.unit="4" lines="5" />
</staffGrp>
</scoreDef>
<measure>
<staff n="1">
<layer n="1">
<beam>
<note dur="8" oct="4" pname="e"/>
<note dur="8" oct="4" pname="f"/>
</beam>
<beam>
<note dur="8" oct="4" pname="e"/>
<note dur="8" oct="4" pname="f"/>
</beam>
<beam>
<note dur="8" oct="4" pname="e"/>
<note dur="8" oct="4" pname="f"/>
</beam>
</layer>
</staff>
<fermata staff="1" tstamp="1" place="above" />
<fermata staff="1" tstamp="1.5" place="above" />
<fermata staff="1" tstamp="2" place="above" />
<fermata staff="1" tstamp="2.5" place="above" />
<fermata staff="1" tstamp="3" place="above" />
<fermata staff="1" tstamp="3.5" place="above" />
</measure>Full measure 2: <scoreDef meter.count="6" meter.unit="8" />
<measure right="end" type="m--1">
<staff n="1">
<layer n="1">
<beam>
<note xml:id="note-L12F1" dur="8" oct="4" pname="e"/>
<note xml:id="note-L13F1" dur="8" oct="4" pname="f"/>
<note xml:id="note-L14F1" dur="8" oct="4" pname="e"/>
</beam>
<beam>
<note xml:id="note-L15F1" dur="8" oct="4" pname="f"/>
<note xml:id="note-L16F1" dur="8" oct="4" pname="e"/>
<note xml:id="note-L17F1" dur="8" oct="4" pname="f"/>
</beam>
</layer>
</staff>
<fermata staff="1" tstamp="1" place="above" />
<fermata staff="1" tstamp="2" place="above" />
<fermata staff="1" tstamp="3" place="above" />
<fermata staff="1" tstamp="4" place="above" />
<fermata staff="1" tstamp="5" place="above" />
<fermata staff="1" tstamp="6" place="above" />
</measure>Imagine that someone wants to change the 6/8 meter in: to 3/4 (either explicitly, or by deleting it and letting the previous meter continue). Then the <measure right="end" type="m--1">
<staff n="1">
<layer n="1">
<beam>
<note xml:id="note-L12F1" dur="8" oct="4" pname="e"/>
<note xml:id="note-L13F1" dur="8" oct="4" pname="f"/>
<note xml:id="note-L14F1" dur="8" oct="4" pname="e"/>
</beam>
<beam>
<note xml:id="note-L15F1" dur="8" oct="4" pname="f"/>
<note xml:id="note-L16F1" dur="8" oct="4" pname="e"/>
<note xml:id="note-L17F1" dur="8" oct="4" pname="f"/>
</beam>
</layer>
</staff>
<fermata staff="1" tstamp="1" place="above" />
<fermata staff="1" tstamp="1.5" place="above" />
<fermata staff="1" tstamp="2" place="above" />
<fermata staff="1" tstamp="2.5" place="above" />
<fermata staff="1" tstamp="3" place="above" />
<fermata staff="1" tstamp="3.5" place="above" />
</measure>To go back to the C.P.E. Bach Fantasia in C major (Wq 61/6) that I used for the measure number letters discussion:
What should the |
Not necessarily. It depends on what remains constant in the change from 3/4 to 6/8. If the 8th notes take the same amount of time in both measures, then the performed duration of the measures is the same. But, if the quarter note in m. 1 is equal to the dotted quarter note in m. 2, then the performed duration of the measures is different. MEI currently expects Other than the trailing "p" (for pulse), which is required because But thinking about your example more carefully, I think you're probably right that |
OK to be more precise, they have the same score-time duration of three quarter notes (as you noticed after thinking more carefully :-). score-time is a symbolic time unit based on rational numbers (integers and fractions) real-time or performance-type is based on physical measurements of time such as seconds, hours, years, eons. These values are real numbers rather than rational numbers, such as
I can see how current Adding |
It's possible to do any of these using Schematron after consensus is achieved. We've discussed this before and I don't think we're going to convince each other, but I see no inconsistency in how MEI deals with |
|
Some example markup using my conception of the new regime-- A whole-measure rest in 11/8: A dotted quarter note: The same dotted quarter note captured by a hand-coder: The same note with both sets of attributes:
It would be useful to also add As @craigsapp suggests, Schematron can be added to disallow (or at least warn against) the simultaneous use of |
Yes, you will never move me from my current musician-based viewpoint: 6/8 is a compound meter with two beats. This time signature comes from the decay of mensural music, representing music which would have been notated with C-Dot in mensural music: the breve (measure) is divided into two semi-breves [beats], and the semi-breve [beat] is divided into three minims [sub-beats]. Ideally this should have been converted to
But my complaint is more that beats have variable widths in different meters rather than about what is called the beat in a particular time signature. We both agree that 2/2 has a beat every half note and 5/4 has a quarter note beat and 3/8 has an eighth note beat. But even these that we agree on have computational complexity built into them due to their dependency on the need to reference a time-signature. The problem with computational processing is illustrated in the above example where the time signature of a measure is changed (or the measure is extracted out of context of the meter). When the beat width changes, then all And there is still the case of extracting a musical excerpt from a score. How should that be handled? For example, if someone wanted to extract a measure from an MEI score to use as a musical example in a paper analyzing the piece, the meter would somehow have to be included in the extraction. That means it would have to be found during the extraction process. When it is included in the musical excerpt, suppose that the author of the paper does not want the time signature shown (typically it is not shown for a musical excerpt, as the music is not for performance and it can mostly be inferred from the duration of the measure and the beaming patterns). Is there a way to make the time signature invisible? With |
I am presuming that you mean: As dots on whole-measure rests got this thread started :-) |
Well, yes and no. I wasn't trying to be entirely accurate, just trying to illustrate that the number of dots displayed has nothing to do with duration. |
|
Or can have nothing to do with duration if we adopt this new approach. |
Yes, being able to split visual dots from logical dots will be useful. One application is that it more or less makes it possible to print mensural music with a CMN typesetting program (i.e., augmentation dots are usually dropped in mensural music). |
|
What about adding optional units to |
|
Sounds like a reasonable proposal, at least something we should discuss, but anything having to do with revision of |
|
Here's where I got to in the ODD before placing #429 on hold -- The element-by-element approach is probably overkill. That is, it might be possible to accomplish the same thing by altering In any case, at this point we can fix the issue with regard to |
Here is some music with irrational durations: |
Is there any reason why
<mRest>is missing inatt.augmentdots?The text was updated successfully, but these errors were encountered: