[MEI-L] clef as milestone element

[Laurent Pugin]

Hi all,

In my opinion, that layout tree should be used for encoding
information that cannot (or can very hardly) be represented in the
logical tree. We probably agree that page information and system
information are a good examples because of the approach taken to
encode the logical tree (i.e., pb and sb are milestones). Now, because
in music notation, there is no clear cutting point between what
belongs to the music itself and what belongs to the layout, we have to
have some flexibility because it is never going to be possible to
decide where to put things if they have to go only into one place. As
a provocation, we could say that measures could also belong to the
layout. It is possible to process the music data without knowing
anything about the measures (except maybe for the repetition bars, and
they could be milestones as well).

I have the impression that it is going to be simpler to avoid to use
the layout tree whenever it is possible. For example, if I have one
single source, and I want to encode x and y position, why shouldn't I
put them in the @x and @y in the logical tree? Now of course, if I
have several sources with different positions, then obviously I cannot
do that. In that case, an option could be to have several layout trees
(one per source), store the x and y position in the respective layout
tree, with its elements pointing to the logical tree. Does it make
sense?

It does not seems very different for me to have several options as we
already have, for example, for representing beams, that is <beam>,
@beam or <beamspan>. That is why I think having a little bit more
flexibility with <clef> would be useful in some uses of MEI.

All the best,
Laurent

On Tue, May 31, 2011 at 4:26 PM, Andrew Hankinson, Mr
<andrew.hankinson at mail.mcgill.ca> wrote:
> Hi Thomas,
>
> I'll answer inline below:
>
>
> <layout>
> ...
> <system id="1">
>  <systemstaff staffref="staff1">
>    <systemstaffdef clef.line= "2" clef.shape= "G">
>    <custos ... />
>  </systemstaff>
> </system>
> ...
> </layout>
>
> <staff n="staff1">
>  <layer>
>   ...
>   <sb systemref="1" />
>   ....
>
> I'm not sure what this would actually give us that we don't already (mostly) have. <systemstaff /> seems to exist only so we could define <systemstaffdef />. Since there is already a relationship between from <sb /> to the <system />, having a pointer the other way is unecessary (also, since multiple <sb />s could refer to the same system, you want the reference going this way).
>
> Actually, we could just put the clef information on <system /> itself; e.g.,
>
> <system clef.line="3" clef.shape="C" />
>
> or something like that. Any thoughts about this?
>
>
> What I'm most interested in is: how will it be possible to define the
> graphical properties of other elements?  How can e.g. the horizontal
> position of notes and the vertical position of articulation marks be
> defined, if desired?  How will elements that are split between
> <system>s be represented, like split beams, slurs or brackets?  Do you
> already have ideas for this?
>
> We're not trying to replicate lilypond or any of the other notational drawing programs, so precise drawing information is "out of scope" for our purposes. We define the horizontal/vertical position of notes and anything else via the <facs /> system, where we draw bounding boxes around all the musical elements and then refer to them by ID. The bounding boxes give the absolute x/y coordinates (ulx uly), (lrx, lry). We're always doing it in reference to a page image, so we have a certain luxury there.
>
> Since elements that are split between systems still belong to a staff, we don't have to worry about it. For example:
>
> <staff>
>   <layer>
>     <note xml:id="n1" />
>     <sb />
>     <note xml:id="n2" />
>   </layer>
>   <slur startid="n1" endid="n2" />
> </staff>
>
>
> I think line 119 has to be:
>  <desc>Points to a system element ID in the layout section.</desc>
> or maybe something like
>  <desc>Points to one or more system element IDs in the layout section.</desc>
> as the type is IDREFS.
>
> In line 2, quotes seem to be missing.
>
> Thanks! I've fixed and committed. The power of community coding at its finest. :)
>
> -A
>
>
> Thomas
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de<mailto: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
>
>