[MEI-L] clef as milestone element
Andrew Hankinson, Mr
andrew.hankinson at mail.mcgill.ca
Tue May 31 09:21:46 CEST 2011
Currently, <clef> isn't allowed directly in <layer>, which was what spurred the whole problem in the first place. And, although this was my first suggestion -- that we do allow <clef> in <layer> -- I think I'm now of the opinion that it could be made a part of <sb/>.
<sb /> is, almost by definition, a child of a staff. A system is a page layout convention, because we can't fit staves on a single continuous piece of paper (unless we're encoding Piano Roll music, but I suspect that's a job for the PRMEI project. :). So we use <sb/> to encode where a system break occurs while still maintaining the music notation as a member of a given staff. So I definitely think that <sb> should be a child or descendent of <staff>.
That, and we don't have measures in our music, so we can't assume a split over two measures.
-Andrew
On 2011-05-31, at 2:58 AM, Maja Hartwig wrote:
> Hi Andrew!
> What about this solution? There would be no need for a new <staffdef>.
>
> <sb/>
> <measure>
> <staff>
> <layer>
> <clef visible="true">
> <layer>
> </staff>
> </measure>
>
> K and M
>
> Am 31.05.2011 um 08:46 schrieb Andrew Hankinson, Mr:
>
>> Thanks, Johannes,
>>
>> I guess I would still have a semantic problem with a particular <staffdef /> defining a staff property while it was a *child* of a given staff. If I understand correctly, you're suggesting:
>>
>> <staff>
>> ...
>> <sb />
>> <staffdef clef.repeat="?true?" />
>> ...
>>
>> In this case, the staffdef would define the properties of its parent, which is what I think I have the biggest semantic problem with. This, and for optimal parsing we would have to have some way of linking which clef it would repeat, which would be problematic (but certainly not impossible) if we were to go with the convention of pre-defining <staffdef>s outside of the "flow" of the notation.
>>
>> -A
>>
>>
>>
>> On 2011-05-31, at 2:36 AM, Johannes Kepper wrote:
>>
>>> Hi Andrew,
>>>
>>> what about solution d): add a new attribute to <staffdef> called @clef.repeat (or similar)? This could provide a rule of thumb which could then be overridden by staffdef/clef if necessary. Seems to be much simpler to me, and <staffdef> already captures defaults like this one.
>>>
>>> Best,
>>> Johannes
>>>
>>>
>>> Am 31.05.2011 um 08:11 schrieb Maja Hartwig:
>>>
>>>> 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>
>>>
>>> <!-- what's the reason for the extra <staffgrp> here? As we're in <layer>already, it should be clear that only this one staff is affected -->
>>>
>>>> <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
>>>>> 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
>>
>>
>> _______________________________________________
>> 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
More information about the mei-l
mailing list