System-level directions #1450
Comments
|
Already implemented with |
|
Thanks. Can you demonstrate an example (using the short example above)? https://music-encoding.org/guidelines/v5/attribute-classes/att.partIdent.html 
You mean And I don't want this: 
|
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="https://music-encoding.org/schema/5.0/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="https://music-encoding.org/schema/5.0/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.0">
<meiHead>
<fileDesc>
<titleStmt>
<title />
</titleStmt>
<pubStmt>
<unpub>This MEI file was created by Verovio's Humdrum converter. When published, this unpub element should be removed, and the enclosing pubStmt element should be properly filled out.</unpub>
</pubStmt>
</fileDesc>
<encodingDesc>
<appInfo>
<application isodate="2024-04-17T09:54:40" version="4.2.0-dev-3d89370-dirty">
<name>Verovio</name>
<p>Transcoded from Humdrum</p>
</application>
</appInfo>
</encodingDesc>
<extMeta>
<frames xmlns="http://www.humdrum.org/ns/humxml">
<metaFrame n="11" token="!!!system-decoration: [(s1,s2)][(s3,s4)]" xml:id="L12">
<frameInfo>
<startTime float="4" />
<frameType>reference</frameType>
<referenceKey>system-decoration</referenceKey>
<referenceValue>[(s1,s2)][(s3,s4)]</referenceValue>
</frameInfo>
</metaFrame>
</frames>
</extMeta>
</meiHead>
<music>
<body>
<mdiv xml:id="mf5dxlc">
<score xml:id="sqstm9l">
<scoreDef xml:id="sjivw2w" midi.bpm="400.000000">
<staffGrp xml:id="s1vbxkrh" bar.thru="false">
<staffGrp xml:id="s1h05qmo" bar.thru="true" symbol="bracket">
<staffDef xml:id="staffdef-L1F4" n="1" lines="5">
<label xml:id="label-L5F4">part 1</label>
<clef xml:id="clef-L6F4" shape="G" line="2" />
<meterSig xml:id="metersig-L8F4" count="4" unit="4" />
</staffDef>
<staffDef xml:id="staffdef-L1F3" n="2" lines="5">
<label xml:id="label-L5F3">part 2</label>
<clef xml:id="clef-L6F3" shape="G" line="2" />
<meterSig xml:id="metersig-L8F3" count="4" unit="4" />
</staffDef>
</staffGrp>
<staffGrp xml:id="s1w5qdjd" bar.thru="true" symbol="bracket">
<staffDef xml:id="staffdef-L1F2" n="3" lines="5">
<label xml:id="label-L5F2">part 3</label>
<clef xml:id="clef-L6F2" shape="C" line="3" />
<meterSig xml:id="metersig-L8F2" count="4" unit="4" />
</staffDef>
<staffDef xml:id="staffdef-L1F1" n="4" lines="5">
<label xml:id="label-L5F1">part 4</label>
<clef xml:id="clef-L6F1" shape="F" line="4" />
<meterSig xml:id="metersig-L8F1" count="4" unit="4" />
</staffDef>
</staffGrp>
</staffGrp>
</scoreDef>
<section xml:id="section-L1F1">
<measure xml:id="measure-L1">
<staff xml:id="staff-L1F4" n="1">
<layer xml:id="layer-L1F4N1" n="1">
<note xml:id="note-L9F4" dur="1" oct="5" pname="g" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L1F3" n="2">
<layer xml:id="layer-L1F3N1" n="1">
<note xml:id="note-L9F3" dur="1" oct="5" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L1F2" n="3">
<layer xml:id="layer-L1F2N1" n="1">
<note xml:id="note-L9F2" dur="1" oct="4" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L1F1" n="4">
<layer xml:id="layer-L1F1N1" n="1">
<note xml:id="note-L9F1" dur="1" oct="3" pname="c" accid.ges="n" />
</layer>
</staff>
<tempo xml:id="tempo-L8F4" place="above" staff="1 3" part="%all" tstamp="1.000000">Allegro</tempo>
</measure>
</section>
</score>
</mdiv>
</body>
</music>
</mei>
|
|
Thanks for the example. The motivation for this feature is related to condensed scores in verovio. In this case it is not directly related to part extraction, but rather the desire to view system-level text in cases where one or more of the staves are condensed that have text (tempo, rit., accel., rehearsal marks, etc). Example: 
Click to view MEI data for above example.<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="https://music-encoding.org/schema/5.0/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="https://music-encoding.org/schema/5.0/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="5.0">
<meiHead>
<fileDesc>
<titleStmt>
<title>Grave</title>
</titleStmt>
<pubStmt>
<unpub>This MEI file was created by Verovio's Humdrum converter. When published, this unpub element should be removed, and the enclosing pubStmt element should be properly filled out.</unpub>
</pubStmt>
</fileDesc>
<encodingDesc>
<appInfo>
<application isodate="2024-04-19T10:07:09" version="4.2.0-dev-3d89370-dirty">
<name>Verovio</name>
<p>Transcoded from Humdrum</p>
</application>
</appInfo>
</encodingDesc>
<workList>
<work xml:id="work0_encoded" type="encoded">
<title type="uniform">
<titlePart type="movementName" analog="humdrum:OMD">Grave</titlePart>
</title>
</work>
</workList>
<extMeta>
<frames xmlns="http://www.humdrum.org/ns/humxml">
<metaFrame n="0" token="!!!OMD: Grave" xml:id="L1">
<frameInfo>
<startTime float="0" />
<frameType>reference</frameType>
<referenceKey>OMD</referenceKey>
<referenceValue>Grave</referenceValue>
</frameInfo>
</metaFrame>
<metaFrame n="23" token="!!!verovio: condense auto" xml:id="L24">
<frameInfo>
<startTime float="36" />
<frameType>reference</frameType>
<referenceKey>verovio</referenceKey>
<referenceValue>condense auto</referenceValue>
</frameInfo>
</metaFrame>
<metaFrame n="24" token="!!!system-decoration: [(s1,s2)][(s3,s4)]" xml:id="L25">
<frameInfo>
<startTime float="36" />
<frameType>reference</frameType>
<referenceKey>system-decoration</referenceKey>
<referenceValue>[(s1,s2)][(s3,s4)]</referenceValue>
</frameInfo>
</metaFrame>
</frames>
</extMeta>
</meiHead>
<music decls="#work0_encoded">
<body>
<mdiv xml:id="m1iwncdw">
<score xml:id="s1i9sp1d">
<scoreDef xml:id="s1ohoddf" midi.bpm="40.000000">
<staffGrp xml:id="s10tqruq" bar.thru="false">
<staffGrp xml:id="s17z2eo8" bar.thru="true" symbol="bracket">
<staffDef xml:id="staffdef-L2F4" n="1" lines="5">
<clef xml:id="c1gi6ole" shape="G" line="2" />
</staffDef>
<staffDef xml:id="staffdef-L2F3" n="2" lines="5">
<clef xml:id="c1ur6af8" shape="G" line="2" />
</staffDef>
</staffGrp>
<staffGrp xml:id="s1alrp7w" bar.thru="true" symbol="bracket">
<staffDef xml:id="staffdef-L2F2" n="3" lines="5">
<clef xml:id="cx3p1gj" shape="F" line="4" />
</staffDef>
<staffDef xml:id="staffdef-L2F1" n="4" lines="5">
<clef xml:id="cx9bqg2" shape="F" line="4" />
</staffDef>
</staffGrp>
</staffGrp>
</scoreDef>
<section xml:id="section-L2F1">
<measure xml:id="measure-L1">
<staff xml:id="staff-L2F4" n="1">
<layer xml:id="layer-L1F4N1" n="1">
<note xml:id="note-L4F4" dur="1" oct="5" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L2F3" n="2">
<layer xml:id="layer-L1F3N1" n="1">
<note xml:id="note-L4F3" dur="1" oct="4" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L2F2" n="3">
<layer xml:id="layer-L1F2N1" n="1">
<note xml:id="note-L4F2" dur="1" oct="3" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L2F1" n="4">
<layer xml:id="layer-L1F1N1" n="1">
<note xml:id="note-L4F1" dur="1" oct="2" pname="c" accid.ges="n" />
</layer>
</staff>
<tempo xml:id="tempo-L1F1" staff="1" tstamp="1.000000">Grave</tempo>
</measure>
<measure xml:id="measure-L5">
<staff xml:id="staff-L5F4N1" n="1">
<layer xml:id="layer-L5F4N1" n="1">
<note xml:id="note-L6F4" dur="1" oct="5" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L5F3N1" n="2">
<layer xml:id="layer-L5F3N1" n="1">
<note xml:id="note-L6F3" dur="1" oct="4" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L5F2N1" n="3">
<layer xml:id="layer-L5F2N1" n="1">
<note xml:id="note-L6F2" dur="1" oct="3" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L5F1N1" n="4">
<layer xml:id="layer-L5F1N1" n="1">
<note xml:id="note-L6F1" dur="1" oct="2" pname="c" accid.ges="n" />
</layer>
</staff>
</measure>
<measure xml:id="measure-L7">
<staff xml:id="staff-L7F4N1" n="1">
<layer xml:id="layer-L7F4N1" n="1">
<note xml:id="note-L8F4" dur="1" oct="5" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L7F3N1" n="2">
<layer xml:id="layer-L7F3N1" n="1">
<note xml:id="note-L8F3" dur="1" oct="4" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L7F2N1" n="3">
<layer xml:id="layer-L7F2N1" n="1">
<note xml:id="note-L8F2" dur="1" oct="3" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L7F1N1" n="4">
<layer xml:id="layer-L7F1N1" n="1">
<note xml:id="note-L8F1" dur="1" oct="2" pname="c" accid.ges="n" />
</layer>
</staff>
</measure>
<measure xml:id="measure-L9" right="dbl">
<staff xml:id="staff-L9F4N1" n="1">
<layer xml:id="layer-L9F4N1" n="1">
<rest xml:id="rest-L10F4" dur="1" />
</layer>
</staff>
<staff xml:id="staff-L9F3N1" n="2">
<layer xml:id="layer-L9F3N1" n="1">
<note xml:id="note-L10F3" dur="1" oct="4" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L9F2N1" n="3">
<layer xml:id="layer-L9F2N1" n="1">
<note xml:id="note-L10F2" dur="1" oct="3" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L9F1N1" n="4">
<layer xml:id="layer-L9F1N1" n="1">
<note xml:id="note-L10F1" dur="1" oct="2" pname="c" accid.ges="n" />
</layer>
</staff>
</measure>
<measure xml:id="measure-L11">
<staff xml:id="staff-L11F4N1" n="1">
<layer xml:id="layer-L11F4N1" n="1">
<rest xml:id="rest-L13F4" dur="1" />
</layer>
</staff>
<staff xml:id="staff-L11F3N1" n="2">
<layer xml:id="layer-L11F3N1" n="1">
<note xml:id="note-L13F3" dur="1" oct="4" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L11F2N1" n="3">
<layer xml:id="layer-L11F2N1" n="1">
<note xml:id="note-L13F2" dur="1" oct="3" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L11F1N1" n="4">
<layer xml:id="layer-L11F1N1" n="1">
<note xml:id="note-L13F1" dur="1" oct="2" pname="c" accid.ges="n" />
</layer>
</staff>
<tempo xml:id="dir-L12F1" place="above" staff="1" tstamp="1.000000">
Allegro
</tempo>
</measure>
<measure xml:id="measure-L14">
<staff xml:id="staff-L14F4N1" n="1">
<layer xml:id="layer-L14F4N1" n="1">
<rest xml:id="rest-L15F4" dur="1" />
</layer>
</staff>
<staff xml:id="staff-L14F3N1" n="2">
<layer xml:id="layer-L14F3N1" n="1">
<note xml:id="note-L15F3" dur="1" oct="4" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L14F2N1" n="3">
<layer xml:id="layer-L14F2N1" n="1">
<note xml:id="note-L15F2" dur="1" oct="3" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L14F1N1" n="4">
<layer xml:id="layer-L14F1N1" n="1">
<note xml:id="note-L15F1" dur="1" oct="2" pname="c" accid.ges="n" />
</layer>
</staff>
</measure>
<measure xml:id="measure-L16">
<staff xml:id="staff-L16F4N1" n="1">
<layer xml:id="layer-L16F4N1" n="1">
<rest xml:id="rest-L17F4" dur="1" />
</layer>
</staff>
<staff xml:id="staff-L16F3N1" n="2">
<layer xml:id="layer-L16F3N1" n="1">
<note xml:id="note-L17F3" dur="1" oct="4" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L16F2N1" n="3">
<layer xml:id="layer-L16F2N1" n="1">
<note xml:id="note-L17F2" dur="1" oct="3" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L16F1N1" n="4">
<layer xml:id="layer-L16F1N1" n="1">
<note xml:id="note-L17F1" dur="1" oct="2" pname="c" accid.ges="n" />
</layer>
</staff>
</measure>
<measure xml:id="measure-L18">
<staff xml:id="staff-L18F4N1" n="1">
<layer xml:id="layer-L18F4N1" n="1">
<rest xml:id="rest-L19F4" dur="1" />
</layer>
</staff>
<staff xml:id="staff-L18F3N1" n="2">
<layer xml:id="layer-L18F3N1" n="1">
<note xml:id="note-L19F3" dur="1" oct="4" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L18F2N1" n="3">
<layer xml:id="layer-L18F2N1" n="1">
<note xml:id="note-L19F2" dur="1" oct="3" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L18F1N1" n="4">
<layer xml:id="layer-L18F1N1" n="1">
<note xml:id="note-L19F1" dur="1" oct="2" pname="c" accid.ges="n" />
</layer>
</staff>
</measure>
<measure xml:id="measure-L20" right="end">
<staff xml:id="staff-L20F4N1" n="1">
<layer xml:id="layer-L20F4N1" n="1">
<rest xml:id="rest-L21F4" dur="1" />
</layer>
</staff>
<staff xml:id="staff-L20F3N1" n="2">
<layer xml:id="layer-L20F3N1" n="1">
<note xml:id="note-L21F3" dur="1" oct="4" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L20F2N1" n="3">
<layer xml:id="layer-L20F2N1" n="1">
<note xml:id="note-L21F2" dur="1" oct="3" pname="c" accid.ges="n" />
</layer>
</staff>
<staff xml:id="staff-L20F1N1" n="4">
<layer xml:id="layer-L20F1N1" n="1">
<note xml:id="note-L21F1" dur="1" oct="2" pname="c" accid.ges="n" />
</layer>
</staff>
</measure>
</section>
</score>
</mdiv>
</body>
</music>
</mei>When using 
How should the "Allegro" be made to be displayed above the second staff when the first one is removed? (and similarly if part three were condensed, the text should move to part 4). |
|
Generally, it's best to avoid procedural mark up ("do this") in a declarative markup ("this is") system. Condensing/expanding a score is a procedural issue that should be resolved by the processing software. However, one could use Alternatively, one could treat all directives as "system level" and rely on the "if it's not already present" clause above to not display directives from other staves above the top staff, if the top staff already has that directive. (That's a long sentence! Is it clear?) This behavior could be turned on/off by a parameter or built into the behavior associated with |
|
There currently is no
Not really 😜 , but I like The basic algorithm for |
|
Not clear, but you figured it out anyway. 👍 |
|
@lpugin is not wanting
Also there is already |
|
I think Since this the issue is essentially related to the use of |
|
I agree that So, I'm not at all certain what the name should be, but I think we should be looking for a name that describes the element's ability to move when the score is condensed -- or perhaps also when it's expanded. We should also consider whether there are other possible values for this yet-unnamed attribute that describe other actions that can be taken when the score is collapsed/expanded. If there are no other possible actions other than "move", then perhaps we can get by with If we think about the possible placement values, then perhaps the name of the attribute will become more clear. |
That is related to the If you are extracting a short score, then you would alter the I don't see a problem with If there were no |
|
There is no |
|
I'd like to roll back the conversation just a bit, when @craigsapp said:
My question is, what purpose is |
There needs to be some distinction between staff-level text and system-level. Staff-level text would not be displayed if the staff is hidden due to being condensed. System-level text would switch to another staff if the staff it is attached to is hidden due to being condensed. If there is no distinction, then things get complicated with condensed scores where text that needs to be displayed at the system level is now showing. Or conversely, text that should only be shown on a particular staff should not move to another staff if the original staff is suppressed due to being removed on a particular line due to the condense option. |
|
Here is an example of the concept of system-level text in Humdrum: 
The text on lines 6 and 9 are not associated with any specific staff, and they instead apply to the entire system. The If I extract a subscore (or if in theory some of the staves were hidden in a condensed score): 
Extracting the parts into a short score of the inner parts, keeping the system-level text still visible above and below the score even though the original staff numbers of the top/bottom staff are different: 
Notice that the system text is not altered and also does not have any staff assignment, since it is calculated automatically (for orchestral scores it gets more complicated where system-level text needs to be attached within the staff such as above the string parts as well as at the top of the system) Here is an example of staff-level text in Humdrum 
Now If I extract the two internal staves, the staff-level text attached to the top and bottom staves disappear since the were attached to staves that have been removed: 
Here is the compiled filter where you can see that the text instructions are now gone from the data: 
MEI |
|
What about See here for previous discussions on |
|
What about implementing rism-digital/verovio#3280 and using that to control the rendering options, instead of adding it to the encoding? |
|
This is not a rendering option per se: there needs to be some attribute for a
In my opinion that is too specific and the functionality could extend beyond the condense feature of verovio. |
|
In your example of system-level text in Humdrum, aren't they just attached to the first staff? I didn't think **kern had the concept of a "system"? |
|
Yes, it looks like they are attached to the first staff (which is the bottom staff in the score):
The difference is that these are "global comments": 
where global comments have two (or more) Local comments would typically be used to add a comment relevant to a particular part, while the global comment would apply in general to all parts or not to any specific part.
|
|
Here is another system-level versus staff-level demo in Humdrum: 
When there is a data spine to the left of the first staff-like spine ( In this configuration: 
I treat the When converting to MEI, both examples will be explicitly attached to the bottom staff, although preferably the first case would be attached to the bottom of the system rather than the bottom staff (visually there would be no difference). |
|
I still don't see the need for a new attribute.
indicates clearly that this directive applies to all parts, i.e. if the first staff is not visible, I would expect it to appear on the next visible one. Whereas
would mean, if the first staff is not shown, the directive is also hidden. |
That seems like it could work although it has a different intended function? i.e., it is related to part extraction according to @pe-ro. I can't think of a specific conflicting case for not having it be used by |
|
Like @craigsapp says, I can't foresee the consequences of relying on Currently, [BTW, I looked into modifying the possible values of I hesitate to name the new attribute Examples:
I'm not wedded to the name "system", but I think it's a good place to start because it draws attention to the difference between staff-attached and system-attached text. I don't think it's needed, but if we want to emphasize the association with condensing a full score, then other possible names might be "condense.place" or "con.place" (too cryptic?). |
|
I think |
|
The concept of a system barely exists in MEI. We have What about something where you can say that a Along with this we might want the ability to address staff groups for |
That is because there is barely any orchestral music in MEI, where system-level text is more common and more complex than small ensembles. And somehow you want to make it as easy as possible to create parts from a full score encoding (although I am specifically wanting a feature to control the condensed score behavior of system-level text with verovio for now). Part extraction of text and condensed scores' texts are fairly well connected -- but not 100% (see example below) which is the concern about using
That is good provided that people do not confuse
This would get complicated, since groups are hierarchical. I am thinking about that in implementing system-level text in the Humdrum-to-MEI converter. But this gets complicated to deal with in large orchestral scores, but it would be somewhat more system-like than group-like. For example if an entire group is condensed out of the score, the text of the group would most likely travel to the next group below in the score (unless that group had its own group-level text). Here is an example from Don Juan by Richard Strauss, which potentially has group-level text:
I highlighted the system level texts, which include a rehearsal mark, the word "tranquillo" and "calando poco" text and line after it. The "calando poco" text behaves as if it were a group-level Viola part: https://vmirror.imslp.org/files/imglnks/usimg/c/cd/IMSLP53620-PMLP12183-StraussR-Op20.Viola.pdf 
"calando poco" becomes "poco calando" (which is very annoying and breaks using Looking at the Oboe part: 
Notice that "poco calando" is present in the part, even though there is no "poco calando" attached to the non-strings group, so that text is really at the system level rather than the group level, and it is just displayed at the group level (so equivalent to |
|
@lpugin, using Boolean values for |
|
@ahankinson said
We have to avoid confusion between 2 different definitions of "all". When there are 3 staves, "all" can mean "each and every one", such as "above staff 1 and above staff 2 and above staff 3". Or it can mean above the entire group of staves. So far, "all" has been used in the first sense. For example, Also, what's the difference between In short, I don't think @craigsapp, the relationship between a score and parts is complex indeed. This is why MEI provides for explicit markup of each of these things separately. In some cases, it's relatively easy to generate one from the other, but problematic in others. I'm pretty sure there can never be a simple, fool-proof solution to this conundrum. It seems to me that conversion of system-level text in Humdrum to MEI for display in Verovio is relatively easy -- convert it to staff-level text. This will result in explicit markup -- system-level text that was above staff 1 will remain attached to staff 1. It seems to me that the inverse -- converting staff-level text in MEI to system-level text in Humdrum -- is the real focus. That's not easy to pull off, but is that really a problem for MEI to resolve? It's not if we remain committed to declarative rather than procedural markup. It's very confusing when you say that part generation and system-level text are different (rightly so IMO) but you bring in examples of the first to illustrate the second. BTW, In any case, I think we should try to keep part generation and system-level text separate. |
I am thinking that If not condensing a score, If staff 1 were condensed (removed) from a particular system line, If staff 2 were condensed, nothing would happen and `@staff="1 3" would be used as-is. If staff 1 and staff 2 were condensed, then nothing would happen since the next lower staff (3) has an explicit assignment for the If staff 1, 2, and 3 were condensed, then staff 4 would be assigned the
So perhaps used three states for The behavior of The behavior of Example: suppose you have four staves and a harm: If staff 4 is condensed, then the In general |
I would say it's because there is no need for a "system" in a virtual musical environment, and thus a symbolic encoding, where a "border" isn't fixed. Systems (in the sense of a 'line break' for a staff) don't really exist, unless you need a fixed width (for human readability / legibility). In common use, "staff" and "system" can be interchangeable, but (at least in my experience of MEI), they mean very specific and different things: A MEI staff is the line of music which is integral to the encoding, whereas a system is a mechanism to limit the width of a staff in a given context (and which can be ignored if you're rendering it in a context that doesn't need systems...)
@pe-ro I was just riffing, and didn't have a fully-formed plan. @lpugin requested a boolean, so I was trying to accommodate that. But I'm 👎 on |
Yes, there will be no fool-proof way of converting between a part in a The Don Juan example is particularly complex, especially the divisi viola parts. Generating cues in parts will take time (but can be simplified by using IDREFs to automatically copy musical content for cues. Page breaks are important for parts so the performers have time to turn the page (digital displays of scores in stead of paper will help minimize that problem). |
Buy you already pointed out I don't care what it is called, as long as the functionality for preserving condensed score text being described here is present. In musical context, a system is a collection of staves (usually attached together with a line at least on the left side) that have the same timeline. "Staff" and "system" are very distinct in my mind. You can have a single-staff system (which is typically a single part or two parts sharing a common staff, and where the concept of staff and system would get confusing). Having a concept of "system" for I will note that Roman numerals did not have a concept of zero (or more specifically positional notation), which is why were are not using them very much anymore... |
|
Returning to this, I'm now thinking @lpugin (and @craigsapp too, originally) are on a reasonable path by suggesting an attribute for A little explanation of the term "detachable" -- the positional attributes ( I haven't thought this through completely. I haven't considered what constitutes a complete list of the circumstances in which an indication can be moved. I'm inclined not to create such a list, though, the same way we don't specify exactly how/when a note can be moved (for collision avoidance, for example). I think |
|
Thinking of possibility that system text may appear on different levels of a score, i.e. above all staves, above every instrument group, below every staff etc. why not use the structural information we have in the Let's take the following as example: <scoreDef>
<staffGrp label="system" xml:id="system">
<staffGrp xml:id="grp01">
<staffDef n="1" xml:id="stf01" />
<staffDef n="2" xml:id="stf02" />
</staffGrp>
<staffGrp xml:id="grp02">
<staffDef n="3" xml:id="stf03" />
<staffDef n="4" xml:id="stf04" />
<staffDef n="5" xml:id="stf05" />
<staffDef n="6" xml:id="stf06" />
</staffGrp>
</staffGrp>
</scoreDef>If we have a tempo that applies to all parts but just appears on top of every staff group, we could point to the IDs in the definition: <tempo place="above" score.level="#grp01 #grp02">Adagio</tempo>This is an alternative to the more simple <dir place="below" score.level="#stf03 #stf04 #stf05 #stf06">calando</dir>This would be the same as with the current <dir place="below" staff="3 4 5 6">calando</dir>This would bring the advantage that it wouldn't matter which staves would actually be visible, because the group structure would still be intact. The more precise <tempo place="between" staff="1 2" score.level="#system">Presto</tempo> |
|
That seems to be a good method, probably the best proposed so far (along the lines I was thinking of at the bottom of the original post :-). And it would be possible to integrate with part extraction, as you note (i.e, still be useful in relation to working with For this full-score example:
The system has two groups at the top level, which is common for orchestral scores: (1) Everything other than the strings The next level down in (1) is: (1a) Woodwinds The Adding this invisible outer grouping to the score would allow the tempo marking to be displayed in all cases where staves are hidden with the condense option in verovio. If the strings are tacet, then their group text would be suppressed; if the woodwinds are tacet (1a), then the group (1) text would still be visible above the brass group (1b). When extracting a score only containing the brass parts, group (1b), the group (1) tempo marking should easily be extractable from the |
|
Sure. You can nest as many <scoreDef>
<staffGrp xml:id="score">
<staffGrp label="Everything other than the strings" xml:id="nonStrings">
<staffGrp xml:id="woodwinds">
<staffDef n="1" xml:id="stf01" />
<staffDef n="2" xml:id="stf02" />
<staffDef n="3" xml:id="stf03" />
<staffDef n="4" xml:id="stf04" />
</staffGrp>
<staffGrp xml:id="brass">
<staffDef n="5" xml:id="stf05" />
<staffDef n="6" xml:id="stf06" />
</staffGrp>
<staffDef n="7" xml:id="stf07" label="timpani" />
</staffGrp>
<staffGrp xml:id="strings">
<staffDef n="8" xml:id="stf08" />
<staffDef n="9" xml:id="stf09" />
<staffDef n="10" xml:id="stf10" />
<staffDef n="11" xml:id="stf11" />
</staffGrp>
</staffGrp>
</scoreDef>This is also allowed: <scoreDef>
<staffGrp>
<staffGrp>
<staffGrp>
<staffGrp>
<staffGrp>
<staffDef n="1" lines="5" meter.count="4" meter.unit="4">
<clef shape="G" line="2" />
</staffDef>
<staffDef n="2" lines="5" meter.count="4" meter.unit="4">
<clef shape="F" line="4" />
</staffDef>
</staffGrp>
</staffGrp>
</staffGrp>
</staffGrp>
</staffGrp>
</scoreDef> |
|
The term |
|
|
|
Yes It may also be useful to allow redundancy: <dir staff="1 8" staffGrp="#nonstrings #strings">some text</dir>Then This method would be computationally efficient: only if the renderer cannot find the staff numbers in When extracting an oboe part from the full score, the same processing would happen, where there is no |
That’s actually why I suggested
Worth checking, but we provide mixed data types on other attributes don’t we? And as much as @lpugin dislikes them, we can define a local override on
Clever as it is, I suspect clearly communicating this expected behaviour in a complete manner will be difficult at best. |
|
Using <dir staff="1" staffgrp="1"/>(Personally I still think that just: <dir staff="1" staffgrp="true"/>would be sufficient, but I am fine with references to |
|
I took |
|
Is there any current use of Two basic possibilities: <scoreDef>
<staffGrp n="1" label="system" xml:id="system">
<staffGrp n="2" xml:id="grp01">
<staffDef n="1" xml:id="stf01" />
<staffDef n="2" xml:id="stf02" />
</staffGrp>
<staffGrp n="3" xml:id="grp02">
<staffDef n="3" xml:id="stf03" />
<staffDef n="4" xml:id="stf04" />
<staffDef n="5" xml:id="stf05" />
<staffDef n="6" xml:id="stf06" />
</staffGrp>
</staffGrp>
<staffGrp n="4">
<staffDef n="7" xml:id="stf07" />
<staffDef n="8" xml:id="stf08" />
<staffGrp/>
</scoreDef>Or: <scoreDef>
<staffGrp n="1" label="system" xml:id="system">
<staffGrp n="3" xml:id="grp01">
<staffDef n="1" xml:id="stf01" />
<staffDef n="2" xml:id="stf02" />
</staffGrp>
<staffGrp n="4" xml:id="grp02">
<staffDef n="3" xml:id="stf03" />
<staffDef n="4" xml:id="stf04" />
<staffDef n="5" xml:id="stf05" />
<staffDef n="6" xml:id="stf06" />
</staffGrp>
</staffGrp>
<staffGrp n="2">
<staffDef n="7" xml:id="stf07" />
<staffDef n="8" xml:id="stf08" />
<staffGrp/>
</scoreDef>I.e., does it matter of the In other words, the enumeration of staffGrp seems basically arbitrary (which would tend to indicate that |
It would be useful to have a concept of system-level directions (
<dir>, and<tempo>in specific, possibly others).Example:
The highlighted text is at the system level. Another example in the same score:
Not exactly the same since it is still staff-level directions, but MEI currently allows duplicating the text onto multiple staves:
Click to view MEI data for above example.
The tempo direction:
The problem is that when extracting parts from a full score, there is not enough information to extract the system-level tempo or rehearsal number other than by inference, which will not always be correct (most particularly when the system-level text is attached to only the top staff, so it would be difficult to differentiate between text that needs to be extracted from the top staff when creating a part from another staff). In the short example, part 2 should be extracted as:
One possibility is to add
@system="true":(where
@staff="1 3"would be optional, or probably best omitted in favor of@system="true"taking over its role).Then in
<scoreDef>elements such as<staffDef>and/or<staffGrp>add@system(or@systemDir, etc.) to indicate wheretempo@systemplacements should occur:When extracting a part, the original
<scoreDef>staffDef@system="true"can be applied to the extracted part (which is whytempo@staff="1 3"should best be removed, since there is no longer a staff 3 and staff 1 has changed (although this could be handled as part of the part extract process).The text was updated successfully, but these errors were encountered: