[MEI-L] clef as milestone element

[Laurent Pugin]

Hi all,

I agree with Andrew that it would be much straightforward to allow
<clef> within <layer>. That does not mean that is has to be present.

Laurent


On Tue, May 31, 2011 at 9:37 AM, Andrew Hankinson, Mr
<andrew.hankinson at mail.mcgill.ca> wrote:
> 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
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>