[MEI-L] clef as milestone element

[Andrew Hankinson, Mr]

Hi Thomas,

No, I think you got it right. The problem is that we need a minimal way of marking a system break within the flow of the music. We came up with the idea of using a @systemref on <sb /> to point to a <system> element in the separate layout tree. That's fine, and fairly unobtrusive. Parsers can ignore any <sb />s if they want to do their own layout, and thus ignore any of the information in the <layout /> tree.

The problem is that <clef> and <custos> occupy an uncomfortable middle ground between being a musical element and a purely layout element. We *could* store them on the <system/> element, and I might be able to be convinced of this, but that would seem to be placing musical structures outside of the flow of the music. I do recognize, however, that I just finished making a case that these were more layout than musical. I'm a study in opposites some days. :)

Because it helps me to visualize how this might look, you're saying:

<layout>
  ...
  <system id="1">
     <clef ... />
     <custos ... />
  </system>
  ...
</layout>

<staff>
   <layer>
     ... 
     <sb systemref="1" />
     ....


-Andrew

(Note: Here's a plug for the latest version of the layout module on the MEI Incubator. Freshly updated! https://gershwin.music.mcgill.ca/trac/mei-incubator/browser/mei-incubator/layout)

On 2011-05-31, at 3:13 AM, TW wrote:

> Hi Andrew,
> 
> do you want the clef element for rendering purposes?  As far as I
> understand, for storing rendering information you're developing a
> separate layout tree anyway, so can't you record the clef (and even
> the system break) there?  Then the musical data doesn't get cluttered
> with layout information.  When there are different readings of
> differing length, then different layouts are required anyway.  When
> generating performance material, different layouts for the score and
> each individual part are required as well (or would this be out of
> scope?).
> 
> I hope I didn't totally misunderstand the issue.
> 
> Thomas Weber
> 
> 
> 2011/5/31 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>> 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
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l