[MEI-L] trills within beams

[Eleanor Selfridge-Field]

Hi, Kristina, Perry, et al.

 

>From my perspective Kristina is prompting a really important question, and
one  response ("more than one pass....") seems to be the inevitable place
where all encoders end up when confronted with real music. It may be
unavoidable, but it is not ideal.

 

What is unsettling  in the responses is that we are putting hierarchy
above music and the needs of encoders. 

When working with MSS, there are dozens of potential distractions, and
making a second pass to capture left-over details requires finding the
exact spot on the folio, checking to see which features were encoded on
the first pass, and, over time, a lot of secondary bookkeeping about what
is finished and what has yet to be done. (I know; I did that kind of
housework for my Marcello catalogue in the 1980s---3000 bitty music files,
each one in need of its own particular notes.)  The  risks of eventual
inaccuracy, incomplete information, and duplication are very real. 

 

Granted we want MEI to work, but if it is optimized for programming
efficiency at the cost of usability, we may need to step back and look for
other solutions. The low level of generalizability of music features
across repertories is widely acknowledged, and we are simply encountering
one instance here. For another example from the same category, consider
this CPE Bach incipit:



 

We used it in our "desk-top publishing IEEE tutorial of 1994. [For all the
examples go to http://www.ccarh.org/publications/reprints/ieee/ --Category
2, Type 1]

 

How would MEI handle it?

 

Eleanor

 

 

Eleanor Selfridge-Field

Consulting Professor, Music

Braun Music Center #129

Stanford University

Stanford, CA 94305-3076, USA

http://www.stanford.edu/~esfield/

http://www.ccarh.org

 

 

 

From: mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de
[mailto:mei-l-bounces+esfield=stanford.edu at lists.uni-paderborn.de] On
Behalf Of Roland, Perry (pdr4h)
Sent: Monday, March 05, 2012 5:50 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] trills within beams

 

Hi, Kristina,

 

MEI is not designed to be encoded in one pass -- some things, such as
trills, pedal markings, text directives, etc., must be captured after the
notes.

 

It might be possible to do what you suggest in some cases but it won't
work all the time because it potentially leads to overlapping hierarchies.
It also means that your proposed <trill> element would have to allow every
other possible element, leading to opportunities for encoders to do
unsupported things.

 

>From snowy (yes, snowy!) Charlottesville,

 

--

p.

 


__________________________
Perry Roland
Music Library

University of Virginia

P. O. Box 400175

Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu

  _____  

From: mei-l-bounces at lists.uni-paderborn.de
[mei-l-bounces at lists.uni-paderborn.de] on behalf of Kristina Richts
[kristina.richts at gmx.de]
Sent: Monday, March 05, 2012 4:26 AM
To: Music Encoding Initiative
Subject: [MEI-L] trills within beams

Hi all, 

 

while encoding the following passage, I just mentioned, that there seems
to be no way to encode the trill right here, as I don't want to extract
this information and place it at the end of the measure.

 

  

 

Why isn't it possible to provide notes within a beam with a <trill>
element, as could be done with single notes, like this:

<trill><note xml:id="m167_s1_e6_A3" pname="b" oct="5" dur="4"
stem.dir="down"/></trill>?

 

Did I miss anything?

 

Best,

Kristina

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120305/ca50ea07/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 20470 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120305/ca50ea07/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 15918 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20120305/ca50ea07/attachment.jpg>