[MEI-L] slur and @curvedir

Mon Feb 2 18:00:12 CET 2015

Hi there,

the example given by Benni is indeed a typical situation and I can 
imagine some more complex. What if this example would be repeated with 
an uninterrupted slur. Would that one be "above-below-above-below"?
As I see it, there are simply two slurs connected. So perhaps it could 
be coded in two <slur> elements with appropriate @tstamp and @dur and 
maybe an additional @rend="connected" or something on the second one.

Klaus

Am Mo, 2. Feb, 2015 um 9:29 schrieb Axel Teich Geertinger <atge at kb.dk>:
> Hi all
> 
> Just out of curiosity: None of the solutions I have seen (@bulge, 
> @bezier, or @curvedir=”above below”) do indicate explicitly where 
> the slur changes position from above the notes to below – that is, 
> where the slur intersects the melodic line, so to speak. I guess that 
> the use of @bezier will give the desired result in most situations, 
> but as the actual rendering of the slur must be dependent to some 
> degree on other factors such as the note spacing or system breaks, I 
> wonder how we can be sure that it will always cross the melodic line 
> at the desired place. With @bulge or @curvedir (with extended values 
> as suggested by Zoltan) this must be even more uncertain, right? In 
> principle, a rendering algorithm may draw the slur in Benni’s 
> example above the first three groups of notes and below only the last 
> group when using @bulge or @curvedir. How do we avoid that?
> 
> One more question about @bulge, again just out of curiosity: Should 
> it be defined that a sequence of values for @bulge must an 
> alternating sequence of positive and negative values, either in the 
> guidelines or the schema? Or would a sequence like the one in the 
> guidelines example (@bulge=”2 1”) make any sense in any situation?
> 
> Best,
> Axel
> 
> 
> Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af 
> Komíves Zoltán
> Sendt: 2. februar 2015 07:08
> Til: Music Encoding Initiative
> Emne: Re: [MEI-L] slur and @curvedir
> 
> Hi Perry,
> 
> 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.
> 
> Best
> Zoltan
> 
> 
> 
> 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.
> 
> --
> 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 [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: 
> http://music-encoding.org/documentation/guidelines2013/userSymbols#index.xml-body.1_div.23_div.3_div.4
> 
> I would have expected the values to be -2 1 for the given example, so 
> I am not sure I understand it correctly.
> 
> Laurent
> 
> On Fri, Jan 30, 2015 at 2:13 PM, Benjamin Wolff Bohl <bohl at edirom.de> 
> wrote:
> Dear MEI-L,
> 
> Freschütz has a question concerning encoding mixed direction slurs.
> 
> 
> 
> 
> In case the picture doesn't come through, please see: 
> https://github.com/Freischuetz-Digital/proofMEIdata/issues/25
> 
> This slur may not be properly encoded in MEI using @curvedir that 
> only allows 'above' or 'below' as values. Nevertheless, using @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 century.
> 
> 
> All the best,
> Benjamin
> 
> _______________________________________________
> 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
> 
> 
-------------- n�chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20150202/8d3fbbef/attachment.html>