[MEI-L] Conventional encoding of suggested accidentals (ficta)?

[Johannes Kepper]

Hi Guiliano and Micah,

@accid.ges is frequently used to make an accidental specified by the key signature explicit for individual notes. In F-maj, you wouldn't use @accid="f" on every b, but adding @accid.ges="f" for every b makes processing much easier. @accid.ges denotes an accidental that is audible, but not visible. However, the absence of the attribute doesn't mean that the b should be played as natural in F-maj. So in most cases, it is just a convenience, but the attribute can be very handy when it comes to specifying the range of written accidentals, which doesn't necessarily end at the barline in certain repertoires.

Regarding the original question, there are more valid answers. My first take would be to keep it as simple as possible. Obviously, the @accid attribute doesn't allow any additional markup to specify it's function. The next best solution is to use the <accid> child of <note>. Besides an @accid attribute, it also has @func (allowed values: 'edit' or 'caution') and @place. Your example could be encoded like so:

<note pname="g" oct="4" dur="2">
	<accid accid="s" func="edit" place="above"/>
</note>

Of course, you could provide an @accid.ges on the note, if this helps your workflow. Editorial markup like <choice> (with a pair of <orig> and <reg>) or (maybe more appropriate) <supplied> is equally possible, but not necessarily required for your purpose (as far as I understand). Since your encoding reflects a translation into a different notational system anyway, I think it's not necessary to make the music ficta even more special than in the solution suggested above. 

Hope this helps,
Johannes


Am 21.06.2013 um 21:21 schrieb Giuliano Di Bacco <gdibacco at indiana.edu>:

> 
> Hello,
> and thanks to Micah for asking this question. I am also interested in how to approach this issue.
>     At the moment I am not working on specific examples but just browsing the guidelines (I take it that we are not talking about rendering the position of the accident above the note but the meaning of it = markup) and was wondering whether the @accid.ges attribute (att.accidental.performed) could handle this. 
>     Guidelines: "records the performed pitch inflection when it differs from the written accidental". It seems that it can be an attribute of <note>. So, what if a note has no written accidental, but an accidental needs to be performed? Here we are not dealing with an editorial amendment proper (<supplied>) but we are to make explicit what is implicit in how the music works (or what the editor believes the original notation means). I thought that @accid.ges may be a possible alternative to <reg> (which otherwise I would be inclined to use).
>     If I am wrong as I suspect ("ges" stands for "gestural"), could somebody please spend a few words on the intended use of accid.ges?
> 
> Thanks & cheers
> Giuliano
> 
> --
> Giuliano Di Bacco
> Director, Center for the History of Music Theory and Literature
> Indiana University Jacobs School of Music
> Bloomington, IN 47405 - USA - www.chmtl.indiana.edu
> Project Director, Thesaurus Musicarum Latinarum
> 
> 
> Micah Walter wrote on 21/06/2013 14:06:
>> Hello, all,
>> 
>> My latest question relevant to encoding modern editions of Renaissance music deals with editorial accidentals, as in the case of musica ficta. Such an accidental is conventionally placed above the single note it affects (see attachment).
>> 
>> Possibly the option that best makes use of the intent of MEI's elements would be to use the <add> tag, containing the single <accid> element. Or maybe <supplied> would work as well. Another solution might be to encode the editorial meaning of such an accidental using the <choice> tag; while <orig> seems to work for the original reading, the best tag for the editorial reading is unclear. <reg>?
>> 
>> Has anyone dealt with this issue before?
>> 
>> Thanks,
>> Micah
>> 
>> <Mail-Anhang.png>
>> 
>> 
>> _______________________________________________
>> 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