[MEI-L] clef as milestone element

[Laurent Pugin]

On Tue, Jun 7, 2011 at 11:22 AM, Johannes Kepper <kepper at edirom.de> wrote:
>
> Am 07.06.2011 um 11:03 schrieb Laurent Pugin:
>
>> On Tue, Jun 7, 2011 at 9:52 AM, Benjamin Wolff Bohl <bohl at edirom.de> wrote:
>>> Hi everybody,
>>>
>>> first thanks for the interesting discussion bringing some clarification on
>>> what the "layout" module is all about, etc.
>>> I'd like to give some inline comments on this summary:
>>>
>>> Am 01.06.2011 18:25, schrieb Andrew Hankinson, Mr:
>>>
>>> Before moving on from the <clef /> discussion, I'd like to try and bring in
>>> a consensus. The way I've heard it there are a number of options:
>>>
>>> 1. <clef /> is allowed directly in <layer />;
>>>
>>> As you say below, this,of course , would solve your immediate problem but
>>> what if thinking of multiple layers on one staff; a clef would also affect
>>> the other layers, or am I mistaken? If so it would make no logical sense as
>>> part on a layer; it should be a direct child of staff.
>>>
>>
>> You are right, but that is not very different from <clefchange> that
>> is also allowed in a <layer>. When it occurs on all layers at the same
>> time, I guess you will put it on all layers. Am I wrong?
>
> Although I have no example in mind currently, I'm pretty sure that I've seen multiple clefs on one staff for different voices (that is, layers).

Yes, I am aware of such cases.

>
>>
>>> 2. <clef /> is allowed in <sb />, explicitly used as a "cautionary" clef.
>>>
>>> On this point I agree with Raffaele (31.05.2011):
>>>
>>> I agree that using clefchange and staffdef for courtesy clef repetitions is
>>> a bit cumbersome, but I would advise against overweighting <pb/> and <sb/>.
>>> In my opinion they should only signify the break and contain nothing. A
>>> custos should occur *before* (or occasionally after) the system break and
>>> not within the system break. If you think about it, that is what happens on
>>> the page. In the same way, the clef repetition should not be attached to sb
>>> or pb.
>>>
>>> 3. Cautionary clefs should be removed from the "musical" flow and placed in
>>> the <layout /> section.
>>>
>>> Actually this would be THE solution if we stick to the opinion, that the
>>> staff should be a virtual "endless" representation of the musical flow. The
>>> cautionary clefs are a rendition phenomenon and do not belong to the logic
>>> of the music but to the layout. In doing so the layout module would somewhat
>>> encode the engraving quality of a specific published edition.
>>
>> So do <custos> because they could be inferred easily. Would you remove
>> them from the logic tree?
>>
>> We have cases where the clef is missing - that is very frequent with
>> typographic prints. How would you encode this? Or when the clef is
>> wrong?
>
> For me, the role for the layout module is not so much the description of an existing source (that's what facsimile and music is for), but instead to allow rendering hints for multiple possible interpretations of the data available in music. Of course it can be used to describe existing sources, but that wasn't my understanding of its intention.
>

It is my understanding too. That is why I am a bit reluctant to put
this in the layout.

> What I am wondering is if there isn't a solution 5. We could just rename clefchange to something less semantic (<clefIndication>?), and provide an attribute @reason with two default values 'cautionary' and 'change'. Actually, it could be merged with the existing <clef>, as both have almost the same set of attributes already. Doing so, <clef reason="cautionary" … /> would be directly allowed within <layer>, without the need for an extra <clefChange>. Could that be a cleaner solution?
>
> What we should make sure is that our changes – if we agree on a solution – are copied to the other corresponding staff features meter and key…

It looks like a good solution to me. I would vote for <clef>, but
<clefIndication> would be fine too. Maybe we can think of another
@reason value. What about reason="sb"?

Laurent

>
> Best,
> Johannes
>
>>
>>>
>>> 4. Keep the status quo and use <staffdef> inside <staff> to indicate a
>>> cautionary clef.
>>>
>>> True, this seems a bit of an overkill...
>>>
>>> While I personally think 2 is the most semantically useful option, I
>>> understand that 1 is perhaps the easiest in the short term.
>>>
>>> I'm not really comfortable with 3, since it removes a musical element from
>>> the "flow" of the staff,
>>>
>>> and 4 seems a bit stilted to me, overloading <staffdef> to not really define
>>> anything new about a parent staff.
>>>
>>> So, I will choose to implement #1 as it seems to solve our immediate issue
>>> for the time being.
>>>
>>> How I propose to solve this is to create a new Incubator project
>>> ("clef-milestone") and create an ODD file that makes the change. This can
>>> then be reviewed by the Technical Group and, if it's found worthy, rolled
>>> into the mainline MEI standard at some point, likely with revisions.
>>>
>>> Should anyone want to use this in another project they can then create their
>>> own customization based on the ODD file. That way they can at least have a
>>> reference back to the deviations from the MEI core.
>>>
>>> In the comments of the ODD file I will reference this discussion so that
>>> there's a way to return to it to re-evaluate the positions put forward here
>>> when it comes time to review the revision.
>>>
>>> Does this sound reasonable?
>>>
>>> Sounds reasonable, all theoretical ideas are only theoretical, whichever
>>> solution we opt for it has to be tested practically (option 4 obviously
>>> failed, as it resulted in this discussion ;-)
>>>
>>>
>>> Best,
>>> Benjamin
>>>
>>> _______________________________________________
>>> 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
>
>