[MEI-L] clef as milestone element
Johannes Kepper
kepper at edirom.de
Tue May 31 09:13:41 CEST 2011
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?" />
> ...
>
No, I would add this at the very first <staffdef>, within <scoredef>. There would be no need to care for the clef at each <sb/> (or <pb/> as well!). But I think your reference to <custos> convinced me that this is also a solution. Also, after thinking twice, I see that a general solution within <scoredef> is rather inconvenient for OMR purposes. I think I would add both options, @clef.repeat (or @clef.rpt, to be more consistent) on <staffdef>, and <clef> within <sb/> and <pb/>. By doing so we have a general solution that's easy to encode by hand, and we have a very specific solution suitable for OMR and catching details of these symbols. Very MEI-like, I'd say.
Johannes
> 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
More information about the mei-l
mailing list