[MEI-L] slur and @curvedir
zolaemil at gmail.com
Mon Feb 2 07:08:28 CET 2015
I think extending the data type of @curvedir attribute could be justified
simply base on the argument of classification: @curvdir provides a
classification mechanism, but this classification is rather incomplete, the
current values of @curvedir do not cover all the cases that are out there
(see Benni's example: nor "above" neither "below" is appropriate, and the
omission of the attribute surely cannot imply what we want to convey, that
is the curve goes also above and below). This has nothing to do with
rendering, since in order to render a slur or phrase mark, the actual curve
needs to be calculated anyway, even when "above" or "below" is applied.
Out of Benni's suggestions I quite like "above-below" / "below-above".
(Note that his question concerns @curvedir not @place.) In fact, it occurs
to me, we could even allow an alternating sequence of the values "below"
and "above". Benni's example would be encoded as <slur curvedir="above
below"/>. This, beside conveying the fact that the curve goes first below,
then above, could also be applied to curves with multiple inflection
points. I have no literary example for this at hand, but wouldn't be
surprised if there was some in existence.
2015-02-01 17:04 GMT+00:00 Roland, Perry D. (pdr4h) <
pdr4h at eservices.virginia.edu>:
> Laurent is correct, the values in the example should be -2 and 1.
> The place attribute is for describing the placement of an entity in
> general terms. For phrase marks and slurs, it also generically describes
> the curvature of the mark, and therefore functions as short hand for a more
> detailed description given by the bulge or bezier attributes. It would be
> possible to add a value to @place for slurs/phrases with multiple
> inflection points, such as "mixed" or perhaps "complex", but this would
> only fulfill a classification purpose -- it wouldn't provide any
> information regarding how to draw the slur/phrase. So, one would still
> need to use @bulge or @bezier for rendering.
> Another complicating factor is that @place is used by a number of
> elements other than slur and phrase. Adding "mixed" directly to @place
> would introduce the possibility of nonsense in the case of, say, <accid> or
> <breath>. Of course, a specialized form of @place for slur/phrase is a
> possibility, but would need careful handling.
> 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 [mei-l-bounces at lists.uni-paderborn.de] on behalf of Laurent
> Pugin [laurent at music.mcgill.ca]
> *Sent:* Sunday, February 01, 2015 8:27 AM
> *To:* Music Encoding Initiative
> *Subject:* Re: [MEI-L] slur and @curvedir
> Hi Benni,
> Have you looked at @bulge? There is an example in the guidelines:
> I would have expected the values to be -2 1 for the given example, so I
> am not sure I understand it correctly.
> On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl <bohl at edirom.de>
>> Dear MEI-L,
>> Freschütz has a question concerning encoding mixed direction slurs.
>> [image: bildschirmfoto 2015-01-30 um 14 05 39]
>> In case the picture doesn't come through, please see:
>> This slur may not be properly encoded in MEI using @curvedir that only
>> allows 'above' or 'below' as values. Nevertheless, using @bezier
>> <https://github.com/bezier> is much more verbose than needed…
>> Maybe a value like 'mixed' / 'above-below' / 'below-above' / 'changing' /
>> 'alternating' would be applicable? Of course the schema would have to be
>> modified to allow this. Are there any comparable values in other parts of
>> the schema?
>> This is no "special", rather quite often in printed music from the 19th
>> All the best,
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 69500 bytes
Desc: not available
More information about the mei-l