[MEI-L] clef as milestone element

[TW]

2011/5/31 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>
> It's a terminology thing. I like thinking about musicians in rehearsal to understand what nomenclature to use. I often hear things like "On the second page, first system, second measure...",

According to my English music notation books, a system is the
"container" of staffs (in the layout sense, my "systemstaffs").  Like
Ted Ross, The Art of Music Engraving and Processing, p. 151: "A
'systemic' barline [,,,] is used for keyboard instruments with
two-stave systems [...]."  Or George Heussenstamm, The Norton Manual
of Music Notation, p. 87: "When two or more staves are connected in
this way they form a system."  In my understanding as a non-native
English speaker, this therefore makes no sense:

>>>
>>> <system clef.line="3" clef.shape="C" />
>>>

because every staff in the system might require a different clef.

>>
>> Then I'm misunderstanding something.  I thought the layout element
>> would be for *generating* a rendition of the music notation, not to
>> describe some facsimile?
>
> No,

This clarifies a lot.

> The idea being that in most cases (should the MEI be imported into a notation editor) you would want to ignore this information and allow the notation editor to do the layout itself, but in some cases (Optical Music Recognition, for example) you would want to be able to define and correlate physical characteristics of the printed image with musical elements -- the location of systems, notes, rests, etc.
>

I'm pretty new to MEI and don't know what MEI's envisaged spectrum of
uses is, but for decent digital editions, I don't think it's enough to
just run the music through a notation editor or a formatter.  It of
course depends on the complexity of the music, but in general, for a
certain level of quality it's necessary that some human editor revises
the notation program's decisions.  And if there are situations that
are maybe musically erroneous or incomplete but shall be presented in
this unedited form, then the notation program might produce garbage or
refuse to process the data.

Another problem I see is that when the MEI data is corrected or
otherwise edited, then you have to do the entire process of formatting
and manual cleanup again, or somehow synchronize with the formatted
data.  And I'm not only thinking about "dead" printouts or vector
graphics renditions.  What about interactive ones that might be able
to display additional information for certain elements, highlight and
(un-)hide elements or integrate with other sources and a special
interface? Can this be achieved without storing the "rendering hints"
and the semantic data in a form that makes the relationship between
graphics and actual data clear?

I thought this was what the layout tree would be about.  So...

>>
>> Are we talking past each other?
>
> I think maybe we are.

we definitely are.

Thomas