[MEI-L] Figured Bass in MEI
Johannes Kepper
kepper at edirom.de
Mon Nov 15 21:44:48 CET 2010
Hi Andrew,
thanks for your input on this.
Am 15.11.2010 um 16:50 schrieb Andrew Hankinson, Mr:
> Thanks Maja and Johannes,
>
> For examples 4 & 5, how are the differences between a
> #6
<figure num="6" accid="s" accid.pos="before"/>
> , slash-6
<figure num="6" accid="s" accid.pos="within"/>
<!--depending on the slash maybe accid="f" instead of "s"-->
> and a 6+
<figure num="6" accid="s" accid.pos="within"/>
> encoded? I'm not well versed in figured bass symbols, but your proposed solution seems to be unclear on this. Perhaps there might be a @sym attribute with values "+, s, n, f, \"? This might be accid.sym, or accid.fb.sym-it will likely not be plain @sym, but I use that just for clarity's sake.
As there are dozens (well, nearly) of different symbols for what we've subsumed as accid.pos="within", we came to this solution (no.4) described in example 10. The idea is to keep the details out of the format, but instead offer a symbol library in the guidelines that can be refered and – even more important – which is easier extensible when new symbols are found. But of course there need to be "default symbols" for all relevant combinations of @accid and @num. Probably those defaults will cover 90% of all cases, but MEI should be capable of encoding thos odd 10% as well.
Btw., if an OMR application runs into a symbol it cannot identify, it seems perfectly reasonable for me to encode it by using nothing more than @sym (see example 6). If there's no clarity regarding @num and @accid, the interpretation should be left to a (human) specialist…
>
> Maybe just "+,\", since it might be assumed that s,n,f are literal if there is no modifying @sym attribute?
>
> (There is a handy chart that I just found that might help with those unfamiliar with figured bass symbols:http://www.robertkelleyphd.com/FiguredBass.pdf)
>
Handy indeed. It does not cover everything, but I haven't found one that does so yet… Thanks for the hint!
> There should also be some attempt to standardize the @place attribute on the <fb> element. I just did a quick look through the schema, and there are various instances of @xxxplacement (e.g., @barplacement), @placement and @place. I would suggest @placement instead of @place, but others might have a better idea of any differences between these.
>
I would suggest to stay with @place, as it is used for fermatas, dynamics and other stuff which basically stands above or below a staff. The current @place also allows "within", but I wouldn't mind about that – there certainly is one weird piece out there with figured bass written on top of the notes … (Don?)
Best,
Johannes
> -A
>
> On 2010-11-15, at 5:28 AM, Johannes Kepper wrote:
>
> Dear all,
>
> although it took us longer than expected, we have finally finished our proposal for a (hopefully) improved encoding of figured bass in MEI. We don't provide a technical schema, but instead offer a couple of examples that might help to slice the problem down. We hope that this paper will start an intense discussion that might pave the way for some changes in the next release of MEI – maybe even a new module!?!
>
> We're looking forward to lots of comments and suggestions for improvement,
> Maja and Johannes
>
>
>
> <proposalFiguredBass.pdf><ATT00001..txt>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
More information about the mei-l
mailing list