[MEI-L] clef as milestone element

[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?

> 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?

>
> 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
>
>