Pitch placement in measure with intermediate clef change

craigsapp commented 7 years ago

A problem occurs in clef assignment for notes when there is a clef change half-way through a measure, and the measure contains more than one layer:

The note which looks like an E6 in m3 is supposed to be a G4, because the G4 is being displayed in bass clef instead of treble clef. This is caused by the clef change in layer 1 affecting notes at earlier times in layer 2 before the clef change of layer 1 should be occurring in layer 2.

This is related to #229, but for cases where the clef change is not at the end of the measure but rather in the middle.

Test MEI 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>
                <date>2016-12-28 10:28:08</date>
            </pubStmt>
        </fileDesc>
        <encodingDesc>
            <projectDesc>
                <p>Transcoded from Humdrum with Verovio version 0.9.13-dev-2f22b77</p>
            </projectDesc>
        </encodingDesc>
    </meiHead>
    <music>
        <body>
            <mdiv>
                <score>
                    <scoreDef xml:id="scoredef-000000007953841">
                        <staffGrp xml:id="m-000000201294796">
                            <staffDef xml:id="staffdef-000000015908972" clef.shape="G" clef.line="2" meter.count="4" meter.unit="4" n="1" lines="5" />
                        </staffGrp>
                    </scoreDef>
                    <section xml:id="section-000000010732145">
                        <measure xml:id="measure-L4" n="1">
                            <staff xml:id="staff-L4F1" n="1">
                                <layer xml:id="layer-L4F1" n="1">
                                    <note xml:id="note-L5F1" dur="4" oct="4" pname="c" accid.ges="n" stem.dir="down" />
                                    <note xml:id="note-L6F1" dur="4" oct="4" pname="d" accid.ges="n" stem.dir="down" />
                                    <clef xml:id="clef-000000112079605" shape="F" line="4" />
                                    <note xml:id="note-L8F1" dur="4" oct="4" pname="c" accid.ges="n" stem.dir="up" />
                                    <note xml:id="note-L9F1" dur="4" oct="3" pname="b" accid.ges="n" stem.dir="up" />
                                </layer>
                            </staff>
                        </measure>
                        <measure xml:id="measure-L10" n="2">
                            <staff xml:id="staff-L10F1" n="1">
                                <layer xml:id="layer-L10F1" n="1">
                                    <clef xml:id="clef-000000031305307" shape="G" line="2" />
                                    <note xml:id="note-L12F1" dur="2" oct="4" pname="g" accid.ges="n" stem.dir="up" />
                                    <clef xml:id="clef-000000170476090" shape="F" line="4" />
                                    <note xml:id="note-L14F1" dur="2" oct="3" pname="g" accid.ges="n" stem.dir="down" />
                                </layer>
                            </staff>
                        </measure>
                        <measure xml:id="measure-L15" n="2" right="end">
                            <staff xml:id="staff-L15F1" n="1">
                                <layer xml:id="layer-L15F1" n="1">
                                    <clef xml:id="clef-000000184701767" shape="G" line="2" />
                                    <note xml:id="note-L18F1" dur="4" oct="4" pname="c" accid.ges="n" stem.dir="down" />
                                    <note xml:id="note-L19F1" dur="4" oct="4" pname="d" accid.ges="n" stem.dir="down" />
                                    <clef xml:id="clef-000000094643353" shape="F" line="4" />
                                    <note xml:id="note-L21F1" dur="4" oct="4" pname="c" accid.ges="n" stem.dir="up" />
                                    <note xml:id="note-L22F1" dur="4" oct="3" pname="b" accid.ges="n" stem.dir="up" />
                                </layer>
                                <layer xml:id="layer-L18F2" n="2">
                                    <note xml:id="note-L18F2" dur="2" oct="4" pname="g" accid.ges="n" stem.dir="up" />
                                    <note xml:id="note-L21F2" dur="2" oct="3" pname="g" accid.ges="n" stem.dir="down" />
                                </layer>
                            </staff>
                        </measure>
                    </section>
                </score>
            </mdiv>
        </body>
    </music>
</mei>

Target rendering:

lpugin commented 7 years ago

Verovio expects the clef changes also to be given in the second layer. One possible improvement would be then not to have them duplicated in the SVG.

craigsapp commented 7 years ago

Verovio expects the clef changes also to be given in the second layer.

That works:

But what is the official way of encoding this sort of case in MEI? It is strange to duplicate an item to simplify processing of the data.

What would happen of the two clefs were different:

The clef is a staff-level item, so a more proper way of encoding (which is probably not allowed in MEI currently), would be to have the clef change as a floating element within the staff:

 <staff>
     <layer>
     <layer>
     <clef tstamp="3">
</staff>

pe-ro commented 7 years ago

<staffDef> can occur between layers. So --

<staff n="1">
  <layer/>
  <staffDef n="1" clef.shape="G" clef.line="2"/>
  <layer/>
</staff>

is the way to do a "staff-level" clef change.

If the clef change is indeed a "layer-level" event, then --

<staff n="1">
  <layer><clef line="2" shape="G"/></layer>
  <layer><clef line="3" shape="C"/></layer>
</staff>

is the way to do it. Verovio can deal with the collision or leave it to a human to resolve. Unfortunately, at present, <clef> doesn't have @ho or @vo attributes to store the horizontal or vertical offsets that might be created by dragging/nudging the clef to a different display location, but that's fixable.

pe-ro commented 7 years ago

Another possibility for "layer-level" clef changes would be to expand the current attributes on <layerDef> to include @clef.* and allow it to occur within <layer>. This would more closely match the situation with <staff>/<staffDef>, but would cause confusion between <layerDef> and <clef>. The preference for <clef> rather than <layerDef> inside <layer> seemed more natural when we addressed this before.

lpugin commented 7 years ago

I am not sure how the in-between layers staffDef helps. I think duplicating the clef on each layer is actually not that bad.

lpugin commented 7 years ago

What would happen of the two clefs were different

Do you have an example of how it should look like?

craigsapp commented 7 years ago

I am not sure how the in-between layers staffDef helps. I think duplicating the clef on each layer is actually not that bad.

It would be analogous to encoding:

As:

<chord>
    <note artic="stacc">
    <note artic="stacc">
    <note artic="stacc">
</chord>

rather than:

<chord>
    <note>
    <note>
    <note>
    <artic artic="stacc">
</chord>

And I seem to remember you complaining about that sort of thing in issue #266 :-)

lpugin commented 7 years ago

Yes, expect that this is not valid:

<staff>
     <layer>
     <layer>
     <clef tstamp="3">
</staff>

craigsapp commented 7 years ago

I like this method for clef changes, particularly when there is more than one layer:

<staff n="1">
  <layer/>
  <staffDef n="1" clef.shape="G" clef.line="2"/>
  <layer/>
</staff>

Questions:

(1) is staffDef@n needed/required? it is redundant with @n on the parent staff element. (2) would staff/staffDef use a @tstamp to place on the staff? (3) is there a reason it is placed after the first layer? Can/should it be placed after all layers?

I can imagine a complication occurring in the rare case when the clef needs to be inserted between grace notes and regular notes at the same timestamp:

Probably a @startid would be used in that case to attach to the staff before the A3.

Verovio does not allow this currently:

$ ./verovio test.mei
[Warning] Unsupported '<staffDef>' within <staff>

So this issue is probably a feature request for <staffDef> within <staff> :-)

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>
                <date>2016-12-28 12:30:35</date>
            </pubStmt>
        </fileDesc>
        <encodingDesc>
            <projectDesc>
                <p>Transcoded from Humdrum with Verovio version 0.9.13-dev-2f22b77</p>
            </projectDesc>
        </encodingDesc>
    </meiHead>
    <music>
        <body>
            <mdiv>
                <score>
                    <scoreDef xml:id="scoredef-000000158818699">
                        <staffGrp xml:id="m-000000123297187">
                            <staffDef xml:id="staffdef-000000148854280" clef.shape="G" clef.line="2" meter.count="4" meter.unit="4" n="1" lines="5" />
                        </staffGrp>
                    </scoreDef>
                    <section xml:id="section-000000159583246">
                        <measure xml:id="measure-L4" n="2" right="end">
                            <staff xml:id="staff-L4F1" n="1">
                                <layer xml:id="layer-L4F1" n="1">
                                    <note xml:id="note-L6F1" dur="4" oct="4" pname="c" accid.ges="n" stem.dir="down" />
                                    <note xml:id="note-L7F1" dur="4" oct="4" pname="d" accid.ges="n" stem.dir="down" />
                                    <note xml:id="note-L9F1" dur="4" oct="4" pname="c" accid.ges="n" stem.dir="up" />
                                    <note xml:id="note-L10F1" dur="4" oct="3" pname="b" accid.ges="n" stem.dir="up" />
                                </layer>
                                <layer xml:id="layer-L6F2" n="2">
                                    <note xml:id="note-L6F2" dur="2" oct="4" pname="g" accid.ges="n" stem.dir="up" />
                                    <note xml:id="note-L9F2" dur="2" oct="3" pname="g" accid.ges="n" stem.dir="down" />
                                </layer>
                                <staffDef n="1" xml:id="staffdef-000033148854280" clef.shape="F" clef.line="4"/>
                            </staff>
                        </measure>
                    </section>
                </score>
            </mdiv>
        </body>
    </music>
</mei>

craigsapp commented 7 years ago

What would happen of the two clefs were different

Do you have an example of how it should look like?

@donbyrd might have some examples :-). There was a Debussy example we were debating last year, but that is not exactly the same (one dominant clef, and a transient secondary clef):

I don't know of any case, and if it did exist it would probably be used to indicate two different voices playing the same music, but reading different clefs (somewhat like a crab canon). In that case they would be placed with a horizontal offset from each other. For a vertical offset, that becomes a meta-clef, since the line on which the F,C,G symbol rests would not be the F,C, or G pitch (this is like the Debussy case).

lpugin commented 7 years ago

So this issue is probably a feature request for <staffDef> within <staff>

You can implement it once MEI is adjusted ;-)

craigsapp commented 7 years ago

You can implement it once MEI is adjusted ;-)

@pe-ro says it is already allowed in MEI ;-)

lpugin commented 7 years ago

It is allowed. However, the guidelines reads "The possibility also exists to include scoreDef and staffDef in staves and layers when the mei-all schema is in use; however, this practice is not recommended for the CMN repertoire."

What is not allowed is @tstamp or @startid in staffDef, so with the encoding you provided above there is no indication about where the clef change occurs.

craigsapp commented 7 years ago

What is not allowed is @tstamp or @startid in staffDef, so with the encoding you provided above there is no indication about where the clef change occurs.

OK, so I will encode duplicate clef changes in each layer for now...

kepper commented 7 years ago

If you add @sameas, it's still clear that there's just one thing on the page…

Am 28.12.2016 um 23:29 schrieb Craig Stuart Sapp notifications@github.com:

What is not allowed is @tstamp or @startid in staffDef, so with the encoding you provided above there is no indication about where the clef change occurs.

OK, so I will encode duplicate clef changes in each layer for now...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

craigsapp commented 7 years ago

Clef changes for multiple layers implemented in the Humdrum-to-MEI converter in commit 276f3a59ba5f77ff65dd574297de979e93840b89

craigsapp commented 7 years ago

If you add @sameas, it's still clear that there's just one thing on the page…

That is good, and brings me closer to accepting the duplicate element :-)

What would the contents of @sameas be? It's data type is URI: http://music-encoding.org/documentation/3.0.0/data.URI

which has a cryptic list of stuff it can be. Does that include an xml:id reference?

craigsapp commented 7 years ago

Here is an example of complications caused by requiring duplicate clefs in different layers:

In this example, two spaces are required in the second layer: one to move to the clef position, and another to move to the first note of the layer.

MEI 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>
                <date>2016-12-29 01:01:01</date>
            </pubStmt>
        </fileDesc>
        <encodingDesc>
            <projectDesc>
                <p>Transcoded from Humdrum with Verovio version 0.9.13-dev-2261ede</p>
            </projectDesc>
        </encodingDesc>
    </meiHead>
    <music>
        <body>
            <mdiv>
                <score>
                    <scoreDef xml:id="scoredef-000000030352628" midi.bpm="84">
                        <staffGrp xml:id="m-000000038000405">
                            <staffDef xml:id="staffdef-000000021113309" clef.shape="G" clef.line="2" key.sig="0" meter.count="4" meter.unit="4" meter.sym="common" n="1" lines="5" />
                        </staffGrp>
                    </scoreDef>
                    <section xml:id="section-000000143075093">
                        <measure xml:id="measure-L9" n="1">
                            <staff xml:id="staff-L9F1" n="1">
                                <layer xml:id="layer-L9F1" n="1">
                                    <beam xml:id="beam-000000151041092">
                                        <note xml:id="note-L10F1" dur="16" oct="4" pname="c" accid.ges="n" stem.dir="up" />
                                        <note xml:id="note-L11F1" dur="16" oct="4" pname="g" accid.ges="n" stem.dir="up" />
                                        <note xml:id="note-L12F1" dur="16" oct="3" pname="b" accid.ges="n" stem.dir="up" />
                                        <note xml:id="note-L13F1" dur="16" oct="4" pname="g" accid.ges="n" stem.dir="up" />
                                    </beam>
                                    <clef xml:id="clef-L14F1" shape="F" line="4" />
                                    <beam xml:id="beam-000000019061278">
                                        <note xml:id="note-L15F1" dur="16" oct="3" pname="a" accid.ges="n" stem.dir="down" />
                                        <note xml:id="note-L16F1" dur="16" oct="4" pname="c" accid.ges="n" stem.dir="down" />
                                        <note xml:id="note-L17F1" dur="16" oct="3" pname="f" accid.ges="n" stem.dir="down" />
                                        <note xml:id="note-L18F1" dur="16" oct="4" pname="f" accid.ges="n" stem.dir="down" />
                                    </beam>
                                    <beam xml:id="beam-000000054549595">
                                        <note xml:id="note-L19F1" dur="16" oct="4" pname="e" accid.ges="n" stem.dir="up" />
                                        <note xml:id="note-L20F1" dur="16" oct="4" pname="d" accid.ges="n" stem.dir="up" />
                                        <note xml:id="note-L21F1" dur="16" oct="4" pname="c" accid.ges="n" stem.dir="up" />
                                        <note xml:id="note-L22F1" dur="16" oct="3" pname="b" accid.ges="n" stem.dir="up" />
                                    </beam>
                                    <beam xml:id="beam-000000061376184">
                                        <note xml:id="note-L23F1" dur="16" oct="4" pname="c" accid.ges="n" stem.dir="up" />
                                        <note xml:id="note-L24F1" dur="16" oct="3" pname="b" accid.ges="n" stem.dir="up" />
                                        <note xml:id="note-L25F1" dur="16" oct="4" pname="c" accid.ges="n" stem.dir="up" />
                                        <note xml:id="note-L26F1" dur="16" oct="4" pname="d" accid.ges="n" stem.dir="up" />
                                    </beam>
                                </layer>
                                <layer xml:id="layer-L9F2" n="2">
                                    <space xml:id="space-L10F2" dur="4" />
                                    <clef xml:id="clef-L14F2" shape="F" line="4" />
                                    <space xml:id="space-L15F2" dur="4" />
                                    <note xml:id="note-L19F2" dots="1" dur="4" oct="3" pname="g" accid.ges="n" stem.dir="down" />
                                    <note xml:id="note-L25F2" dur="8" oct="3" pname="f" accid.ges="n" stem.dir="down" />
                                </layer>
                            </staff>
                        </measure>
                    </section>
                </score>
            </mdiv>
        </body>
    </music>
</mei>

lpugin commented 7 years ago

Yes, but as long as there is not a better way to encode this in MEI we need to do this. If we take the analog of chord and staccato, you seem to think that we should not duplicate the information and that this

<chord>
    <note artic="stacc">
    <note>
    <note>
</chord>

would be OK. I do not.

pe-ro commented 7 years ago

It is allowed. However, the guidelines reads "The possibility also exists to include scoreDef and staffDef in staves and layers when the mei-all schema is in use; however, this practice is not recommended for the CMN repertoire."

That language was added to appease those who disagree with allowing <scoreDef> and <staffDef> between lower level elements like <layer>. It's not necessarily authoritative. ;-)

pe-ro commented 7 years ago

There's a proposal to disallow scoreDef and staffDef between measures (https://github.com/music-encoding/music-encoding/issues/324). I assume applies to their position between layers as well. But let's discuss this over there.

craigsapp commented 7 years ago

It is allowed. However, the guidelines reads "The possibility also exists to include scoreDef and staffDef in staves and layers when the mei-all schema is in use; however, this practice is not recommended for the CMN repertoire."

That language was added to appease those who disagree with allowing <scoreDef> and <staffDef> between lower level elements like <layer>. It's not necessarily authoritative. ;-)

I was wondering about this: why is <scoreDef> allowed inside <staff>? I can see the point of allowing <staffDef> since it would be in the scope of the staff it belongs to.

lpugin commented 7 years ago

Sorry, but I am still not clear how the use of staffDef within layer or staff can avoid the duplication we have with clef. How should the last measure of the first example given by @craigsapp be encoded?

pe-ro commented 7 years ago

@lpugin -- I was just responding to Craig's prompt that perhaps <clef> should be allowed to occur between layers by pointing out that <staffDef> can already be a "stand-in" for <clef> in that location. But, I don't think there's any way to avoid duplicating the clef change when there are multiple layers.

I would encode m. 3 of the first example, this way --

<measure n="3" right="end">
  <staff n="1">
    <layer n="1">
      <clef shape="G" line="2" xml:id="clef1"/>
      <note dur="4" oct="4" pname="c" accid.ges="n" stem.dir="down"/>
      <note dur="4" oct="4" pname="d" accid.ges="n" stem.dir="down"/>
      <clef shape="F" line="4" xml:id="clef2"/>
      <note dur="4" oct="4" pname="c" accid.ges="n" stem.dir="up"/>
      <note dur="4" oct="3" pname="b" accid.ges="n" stem.dir="up"/>
    </layer>
    <layer n="2">
      <clef shape="G" line="2" xml:id="clef3" sameas="#clef1"/>
      <note dur="2" oct="4" pname="g" accid.ges="n" stem.dir="up"/>
      <clef shape="F" line="4" xml:id="clef4" sameas="#clef2"/>
      <note dur="2" oct="3" pname="g" accid.ges="n" stem.dir="down"/>
    </layer>
  </staff>
</measure>

Using @sameas seems like a reasonable way to avoid rendering the clef more than once. Clefs 1 and 2 could also have @sameas attributes, but they're not required to establish the relationship, since "sameas" is reciprocal. It's probably best to use @sameas as a back reference. That way, all the references go in a single direction, and to something that's already occurred.

craigsapp commented 7 years ago

That sounds good to me, and it would be good for the @sameas to work as you describe: there would be a primary object with no @sameas entry, and any secondary references to it would use @sameas to point to it.

@lpugin: see issue #401 :-)

kepper commented 7 years ago

one more thing to add: Whenever I use @sameas, I copy all attributes and child elements from the element pointed at over to the pointing element, and overwrite them with local attributes when available (with the exception of the @xml:id). I thought that this is described somewhere in the Guidelines, but apparently it isn't – my fault. However, this means that the clef in the second layer doesn't have to specify @line and @shape, but instead takes the values from it's encoding in the first layer… I see the problem with required attributes (not in this case), and maybe that's the reason why the Guidelines don't introduce this possibility, but it helps to deal with conflicting information…

Am 29.12.2016 um 20:46 schrieb Craig Stuart Sapp notifications@github.com:

That sounds good to me, and it would be good for the @sameas to work as you describe: there would be a primary object with no @sameas entry, and any secondary references to it would use @sameas to point to it.

@lpugin: see issue #401 :-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

craigsapp commented 7 years ago

However, this means that the clef in the second layer doesn't have to specify @line and @shape, but instead takes the values from it's encoding in the first layer

That is handy (the English one, not the German one), as it prevents the possibility of the clefs from being different (and therefore not really same-as).

So @pe-ro, what about this encoding:

<measure n="3" right="end">
  <staff n="1">
    <layer n="1">
      <clef shape="G" line="2" xml:id="clef1"/>
      <note dur="4" oct="4" pname="c" accid.ges="n" stem.dir="down"/>
      <note dur="4" oct="4" pname="d" accid.ges="n" stem.dir="down"/>
      <clef shape="F" line="4" xml:id="clef2"/>
      <note dur="4" oct="4" pname="c" accid.ges="n" stem.dir="up"/>
      <note dur="4" oct="3" pname="b" accid.ges="n" stem.dir="up"/>
    </layer>
    <layer n="2">
      <clef xml:id="clef3" sameas="#clef1"/>
      <note dur="2" oct="4" pname="g" accid.ges="n" stem.dir="up"/>
      <clef xml:id="clef4" sameas="#clef2"/>
      <note dur="2" oct="3" pname="g" accid.ges="n" stem.dir="down"/>
    </layer>
  </staff>
</measure>

This would increase processing time to search for the element being referred to. But this could be minimized by first searching in the current <staff> node, where the reference is expected to be located.

pe-ro commented 7 years ago

@craigsapp -- The previous example is already valid. Yay! But it would be meaningful only as long as the MEI.analysis module is switched on. If we were to proceed as planned with a stripped-down version of MEI that didn't include this module, this markup would no longer validate. In this scenario, removing the offending @sameas attribute would make it valid, but then it would be missing essential data; that is, info normally contained in the @shape and @line attributes.

pe-ro commented 7 years ago

This latest turn has got me thinking that it would be a good idea to separate attributes in the att.common.anl set (copyof, corresp, next, prev, sameas, synch) from the attributes used for musical analysis (deg, inth, intm, mfunc, pclass, psolfa) and from the attribute used for linking data with performances (when). The goal would be to make them independent (mostly) so the common set could be kept in all other derivative schemas.

kepper commented 7 years ago

I agree that those should be in one of the core modules. I believe it's sufficient to turn them off by removing the att.common.anl class (instead of the analysis module).

Am 29.12.2016 um 21:56 schrieb pe-ro notifications@github.com:

This latest turn has got me thinking that it would be a good idea to separate attributes in the att.common.anl set (copyof, corresp, next, prev, sameas, synch) from the attributes used for musical analysis (deg, inth, intm, mfunc, pclass, psolfa) and from the attribute used for linking data with performances (when). The goal would be to make them independent (mostly) so the common set could be kept in all other derivative schemas.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

craigsapp commented 7 years ago

This latest turn has got me thinking that it would be a good idea to separate attributes in the att.common.anl set (copyof, corresp, next, prev, sameas, synch) from the attributes used for musical analysis (deg, inth, intm, mfunc, pclass, psolfa) and from the attribute used for linking data with performances (when). The goal would be to make them independent (mostly) so the common set could be kept in all other derivative schemas.

What is the definition of analysis in the MEI context? I would say that musical analysis attributes/element would be good to separate from the core encoding infrastructure. But I would say that @sameas is not a music analysis feature, and is required for for basic encoding infrastructure.

Can @sameas have multiple functions? In the current context <clef sameas="#clef1"> this is a technical use, meaning "identical to". This could also be used in a looser sense, meaning "similar to", such as in a music analysis application.

pe-ro commented 7 years ago

But I would say that @sameas is not a music analysis feature, and is required for for basic encoding infrastructure.

Exactly. Right now, however, @sameas and other attributes are bundled into a single module.

Can @sameas have multiple functions? In the current context <clef sameas="#clef1"> this is a technical use, meaning "identical to". This could also be used in a loser sense, meaning "similar to", such as in a music analysis application.

It's always better if a single attribute has only a single function. @sameas is intended to be taken literally; that is, is literally the same thing even though it's encoded twice. @corresp has the looser definition; that is, these things are similar to each other somehow.

craigsapp commented 7 years ago

It's always better if a single attribute has only a single function. @sameas is intended to be taken literally; that is, is literally the same thing even though it's encoded twice. @corresp has the looser definition; that is, these things are similar to each other somehow.

That is good, so in my made-up terminology;

@sameas means "identical to" @corresp means "similar to"

pe-ro commented 7 years ago

Ok.

rism-digital / verovio

Pitch placement in measure with intermediate clef change #400