[MEI-L] clef as milestone element

[Laurent Pugin]

> Yes. You wouldn't need to define a physical location to a *staff*, since a staff is really the concatenation of systems. 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...", which to me gives a fairly accurate coordinate system on where to find the item in question.
>

That is just because you already know which staff to look at :)

Laurent


>
>>
>>> Actually, we could just put the clef information on <system /> itself; e.g.,
>>>
>>> <system clef.line="3" clef.shape="C" />
>>>
>>
>> I'm confused.  A clef is on the staff level, not the system level, right?
>
> This was my original out-loud thinking. *Most* traditional uses of clef is staff-level, since the clef at the beginning of every *system* is a courtesy clef--an aid to the performer. HOWEVER, if you want to encode the location of <clef> on a system, it is not technically a new staff definition, but also not a clef change. So we end up with a courtesy clef that cannot be encoded.
>
>
>>
>>>
>>> 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.
>>>
>>
>> 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, the layout element would be to separate the physical characteristics of a page image from the musical characteristics. 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.
>
>>
>>> 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'm thinking of the layout information.  A split element consist of
>> two or more separate graphical elements.  If positioning information
>> shall be recorded, then a single set of positioning attributes is not
>> enough.
>>
>> Are we talking past each other?
>
> I think maybe we are. The layout element is (currently) useful for our specific purpose in OMR. How musical shapes are drawn (e.g., vector graphics), and where they should be positioned are, in my opinion, already covered by formats like PostScript.
>
> We published a paper at last year's ISMIR that describes our use of the <facs> system for defining musical element positions on an image. If you're interested, you can read it here: http://transientstudent.net/sites/transientstudent.net/files/hankinson_ismir2010_paper.pdf
>
> -Andrew
>
>
>>
>> Thomas
>>
>> _______________________________________________
>> 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
>
>