[MEI-L] comment on MEI @clef.trans values

[Byrd, Donald A.]

Sounds good. I'm pretty sure Craig was talking about was just the MEI 
encoding, not the string displayed, and so was I, but -- now that you 
mention it -- that probably wasn't clear to everyone!

--DAB


On Mon, 17 Aug 2009 11:03:29 -0400, "Roland, Perry (pdr4h)" 
<pdr4h at eservices.virginia.edu> wrote:

> Hi, everybody,
>
> It's important to remember that our principal goal is to identify and
> name features within the notation that we want to represent.  What
> label gets displayed when the feature is rendered is of secondary
> importance.  For example, obviously we want to mark the fact that a
> clef may indicate octave transposition.  The major points to be
> captured are:  how much transpositon (1,2, or more octaves?) and in
> which direction (up or down?).  Whether the printed label says
> "15va", "15ma", or something else, is secondary.
>
> I admit I made a mistake in conflating the important stuff with the
> label when I chose to use a single attribute aiming to encode all 3
> things.  In order to correct my error, clear up the confusion, and
> allow an arbitrary label to be displayed, I think the octave element
> should serve as a model, since it has 2 attributes: 1 for the amount
> of displacement (dis) and one for the direction of displacement
> (place).
>
> Using attributes similar to those on <octave>,
>
> <clef line="2" shape="G" dis="8" dis.place="above">an octave up</clef>
>
> would result in a G clef with either '8' above it (standard) or 'an
> octave up' (non-standard) rendered above it, depending on the
> rendering software.  The PCDATA content will permit any string,
> "15va", "15ma", or anything else, as well as capture of typographical
> details of the string.
>
> The values '8', '15', and '22' will be permitted in @dis while
> @dis.place will allow 'above' and 'below'.
>
> On some elements, the attributes will have to be named slightly
> differently, e.g., clef.dis and clef.dis.place on <scoredef>.
>
> --
> p.
>
> __________________________
> Perry Roland
> Digital Curation Services
> University of Virginia Library
> P. O. Box 400155
> Charlottesville, VA 22904- 4155
> 434-982-2702 (w)
> pdr4h at virginia.edu
> ________________________________________
> From: mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de
> [mei-l-bounces+pdr4h=virginia.edu at lists.uni-paderborn.de] On Behalf
> Of Byrd,  Donald A. [donbyrd at indiana.edu]
> Sent: Saturday, August 15, 2009 4:49 PM
> To: mei-l at lists.uni-paderborn.de
> Subject: Re: [MEI-L] comment on MEI @clef.trans values
>
> On Wed, 12 Aug 2009 16:22:12 -0700, Eleanor Selfridge-Field
> <esfield at stanford.edu> wrote:
>> Hi, Don,
>>
>> 15ma [quindicesima] makes a lot more sense than 15va [compounded from ottava
>> + ottava], but 15mb makes no sense at all.
>
> Yes, it's a silly abbreviation; I'm not particularly attached to it :-) .
>
>
>> I'm not persuaded that just
>> because an instance of something exists, it needs to be accommodated in
>> Round 1 of MEI.
>
> I agree completely -- in fact, handling everything that's ever been
> used is out of the question, at least for several years; there are WAY
> too many obscure features people have used -- and 15ma bassa is well
> below the level of importance that MEI Round 1 needs to handle. The
> Byrd & Isaacson table lists 15ma and 15ma bassa as "very desirable",
> not required -- and for 15ma bassa, just "desirable" is surely more
> accurate. However, unlike almost everything in music notation, octave
> signs form a simple, closed set of exactly four signs, of which two are
> obviously essential and we're talking about doing one more, so it seems
> to me it'd be worth taking care of the fourth now just to get it out of
> the way. (I have to admit now I think I once saw a "22ma" sign
> somewhere! But I don't think that's even worth considering.)
>
>
>> It might be good just to keep a list of exceptions that might be desirable
>> for eventual inclusion (cf. the Dagstuhl core, which consigns them to Level
>> 2).
>>
>> For exceptions of a more arbitrary nature (and Augenmusik in general), an
>> annotation should suffice. This is especially true for works of recent
>> decades, because in the current copyright climate, their encoding is
>> unlikely.
>
> I'll comment separately on all of this.
>
> --Don
>
>
>>
>> Eleanor
>>
>>
>>
>> -----Original Message-----
>> From: mei-l-bounces at lists.uni-paderborn.de
>> [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of Byrd, Donald A.
>> Sent: Tuesday, August 11, 2009 6:35 PM
>> To: mei-l at lists.uni-paderborn.de
>> Subject: Re: [MEI-L] comment on MEI @clef.trans values
>>
>> I vote for changing 15va => 15ma; also adding 15mb, which has actually
>> been used in published music (if anyone cares, I know of three
>> occurrences, one in a well-known piece: Cowell's The Tides of
>> Manaunaun).
>>
>> --Don
>>
>>
>> On Mon, 10 Aug 2009 13:44:12 -0700, Craig Sapp <craigsapp at gmail.com> wrote:
>>
>>> Hello MEIers
>>>
>>> In DTD 1.9b, I notice that there are
>>> three choices for @clef.trans which is a
>>> transposition value for a clef sign:
>>>
>>> 8va = transpose up one octave higher than written
>>> 8vb = transpose down one octave lower than written
>>> 15va = transpose up two octaves.
>>>
>>> 8va is the abbreviation for "ottava" in Italian.
>>> 8ba is the modern abbreviation for "ottava bassa"
>>>
>>> 15va does not exists as an abbreviation in Italian,
>>> but is rather "15ma" which stands for quindicesima,
>>> or a perfect 15th (two octaves).
>>>
>>> It may be better to change "15va" to "15ma".  And if so,
>>> then also add "15mb" represending "quindicesima bassa"
>>> for playing two octaves lower for completeness.
>>>
>>> Alternatively, the transposition could be given numerically
>>> as in +1 for 8va, -1 for 8ba, +2 for 15ma and -2 for 15mb. Or,
>>> semitones could be used: +12 for 8va, -12 for 8vb, +24 for
>>> 15ma, and -24 for 15mb.
>>>
>>> -=+Craig
>>>
>>>
>>
>>
>>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>


--
Donald Byrd
Senior Scientist
Adjunct Associate Professor of Informatics & Music
Indiana University, Bloomington