[MEI-L] clef as milestone element

[Andrew Hankinson, Mr]

Hi Kristina & Maja,

Thanks for getting in touch and keeping the conversation going!

The problem is that a <sb> doesn't necessarily imply a different <staff>, and thus a whole new <staffdef> seems semantically awkward. While it is technically possible to put <staffgrp> and <staffdef> *inside* a staff, it does not make a whole lot of sense to me in this particular case. I think this is why the <clefchange /> element exists in the first place -- so that you can suggest a milestone without redefining a whole new staff.

After sending my last e-mail, I realized there may be some precedent for associating <clef> and <sb> -- the <custos> element, which is currently allowed as a child to <sb>. It is very similar to a clef in this specific use. It has no musically semantic value (both serve as a guide to the performer), but both supply information that is specific to a particular layout. In other words, if you could write the whole work on a single, continuous staff, you would have need for neither <custos> nor <clef> (once it has been defined and assuming it doesn't change).

It's true that <clef> *can* be an independent element; indeed, I think it will be used within <staffdef> and <clefchange> for most cases where it serves as the primary indicator of pitch locations. But allowing in to be tied to <sb /> will also allow us to encode the particular use of a <clef> as a performer guide too.

So, I guess what I'm advocating is one or both of the following:

<staff n="1">
 <layer n="1">
   <sb n="1" clef.line="3" clef.shape="F" />
   <note pname="f" oct="3"/>
   <note pname="g" oct="3"/>
   ...
   <sb n="2">
      <clef line="3" shape="F" />
   </sb>
   <note pname="c" oct="3"/>
   <note pname="d" oct="3"/>

   ...etc...

-Andrew

On 2011-05-31, at 2:11 AM, Maja Hartwig wrote:

Hi Andrew!
We think you are right, that a clefchange makes no sense within this context.
Did you already tried this solution?

                       <measure>
                           <staff>
                               <layer>
                                   <note/>
                                 <sb/>
                                   <staffgrp>
                                       <staffdef>
                                           <clef line="2" shape="G"/>
                                       </staffdef>
                                   </staffgrp>
                                   <note/>
                               </layer>
                           </staff>
                       </measure>

Nothing against crazy solutions ;-), but in our opinion, allowing <clef> within <sb>  is not the best way to encode this, because <sb>  applies only the layout as you said, but the <clef> should be  regarded as an independent element. If the clef appears in the second measure  after a systembreak e.g, you have to indicate that, too, but it has nothing to do with a <sb>.

        <measure n="1"/>
                        <sb/>
                        <measure n="2"/>
                        <measure n="3">
                            <staffgrp>
                                <staffdef n="1" clef.line="2" clef.shape="G"/>
                            </staffgrp>
                            <staff n="1">
                                <layer>
                                    <note/>
                                </layer>
                            </staff>
                        </measure>

We would prefer to keep it within <staffdef>.

Best,
Kristina and Maja





Am 31.05.2011 um 01:18 schrieb Andrew Hankinson, Mr:

Hi all,

tl;dr Should clefs be considered a milestone element?

The <clef> element in MEI is currently only allowed within <clefchange> and <staffdef> elements. I can understand why, since <staff> is supposed to reflect musical linearity and not be affected by system breaks, which is more a physical artifact of page layout. So, a <clef> should only occur if a) it's part of the staff definition, or b) it's changing.

*However*, an interesting question comes up when encoding clefs at the beginning of systems. Currently, the only way to encode this is to wrap a <clef> in a <clefchange>, but for most of the time, it's not actually changing; it's only a "courtesy" clef.

So, to give an example. Suppose the following:

<staff n="1">
 <layer n="1">
   <sb n="1"/>
   <clef line="3" shape="F"/>
   <note pname="f" oct="3"/>
   <note pname="g" oct="3"/>
   ...
   <sb n="2" />
   <clef line="3" shape="F"/>
   <note pname="c" oct="3"/>
   <note pname="d" oct="3"/>

   ...etc...

This is currently invalid MEI, but I'm not really sure how to capture the clefs at the beginning of each system without a) incorporating them into a <clefchange> (semantically wrong), b) allowing <clef> directly within layer, or (really crazy) c) changing <sb> to include clef information (e.g., allow <clef> within <sb>, and/or add @clef.shape and @clef.line directly on <sb>.

What I'd like to suggest is option b), but I'm sure there's a very good reason why I'm wrong. :)

-Andrew
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l

_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l