[MEI-L] clef as milestone element

[Andrew Hankinson, Mr]

On 2011-05-31, at 4:23 PM, TW wrote:

> 2011/5/31 Andrew Hankinson, Mr <andrew.hankinson at mail.mcgill.ca>:
>> 
>> <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 />.
> 
> I don't understand how the staff's position can be recorded without
> having some kind of staff element in the layout tree?

The location of a staff doesn't have to be recorded, since it's not a "physical" thing -- it's really just a way of recording a continuous sequence of notes. A system, however, does have a physical location.

Using the facsimile references, you would record locations of systems by using pointers between elements to refer to a zone on an image. In a grossly truncated example:

<facs id="f1" ulx="1" uly="1" lrx="10" lry="10" />
...
<system facs="f1" />
...

This would define a 9px square box at (1,1) and (10,10) on the image that corresponds to a (very tiny) system on the image. The "f1" id on facs is the same as the value given in the @facs attribute on system.

> 
>> 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).
>> 
> 
> You mean @staffref?

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. 


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