[MEI-L] slur and @curvedir

Tue Feb 3 15:30:51 CET 2015

Hi Johannes,

First, I didn't intend to endorse the idea of breaking a single slur with multiple inflection points into multiple slurs, only to indicate that it might be a possibility worthy of discussion. :-)  I think you've demonstrated the problems that might be created by taking this approach.

However, I'm confused by what appears to be a postscript to your comments --

"we have to be very clear about the different intentions an encoder may have. If the task is to preserve a specific rendering, there seems no way around @bezier. However, @bezier is of little help for analytical purposes. Here, I believe Axel's question about the "turning points" seems very important."

Obviously, @bezier addresses only the visual qualities of the slur.  But, what are the analytical purposes you mention?  What do the so-called "turning points" have to do with analysis?  Is the shape of the slur meaningful, say across sources?  If so, assuming that @bezier accurately captures the slur's shape, then why not compare the values in @bezier for the same slur in the two sources?

--
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 Johannes Kepper [kepper at edirom.de]
Sent: Tuesday, February 03, 2015 5:22 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] slur and @curvedir

Dear all,

I think Perry is right in pointing out the different use cases that result in different solutions. For rendering, @bezier is probably the first choice, but it doesn't help much for analytical purposes. Here, I would probably follow Perry's advice, that is, split up the slur into two (or more, depending on the example) separate slur elements with a clear @curvedir, and then use @join to recombine them. Even though I would probably take this path, there are some caveats I'm not completely settled with yet.

First, it seems like our encodings are incompatible – we can't have the rendering-specific @bezier on one element, and two elements for the "analytical" aspect. Splitting @bezier also into two separate curves on the two slur elements is probably impossible, since @bezier doesn't control the width of the curve, and thus not the tips where our two slurs connect – the visual result would be different than what we want to achieve (but I may be perfectly wrong about this). In essence, the graphical precision would suffer from being combined with the analytical information.

The other issue I can see is that @join would be used in a slightly different way than in other occasions. The main purpose of @join (at least for me) is to indicate that two measures are actually one, that is, not all beats of a measure are written before a system or page break. While MEI allows to insert <pb/> and <sb/> in every layer, I prefer to close the measure instead, insert one break that doesn't have to be coordinated with others, open the next measure, and indicate that this new measure is a continuation of the one before the break. In this setup, @join is used to indicate that two separate graphical entities form one logical entity. In Benni's slur example, we would use it the other way round, that is, we split up one graphical entity into multiple logical entities. I wonder what this means and have to admit that I'm not even decided if that's a problem or not. Opinions?

Johannes

we have to be very clear about the different intentions an encoder may have. If the task is to preserve a specific rendering, there seems no way around @bezier. However, @bezier is of little help for analytical purposes. Here, I believe Axel's question about the "turning points" seems very important.

Am 02.02.2015 um 20:29 schrieb Roland, Perry D. (pdr4h) <pdr4h at eservices.virginia.edu>:

>
> Hi Klaus,
>
> There is already a @join attribute provided on slur (and phrase) for this purpose -- sort of.  @join contains ID references to the other slurs that form a single entity.  But, this is more for analytical purposes than for rendering. The assumption is that slurs that are broken over system or page boundaries need relating to each other.  However, I leave it to Benni to decide if this solution fits his slur markup problem.
>
> I'm not sure that @join could be used for rendering unless the point(s) at which the different slurs join are specified very precisely. In addition, two independently drawn slurs may not achieve the same (beautiful?) effect as one smooth, undulating curve.  Of course, this could be renderer-dependent.
>
> --
> 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 Klaus Rettinghaus [klaus.rettinghaus at gmail.com]
> Sent: Monday, February 02, 2015 12:00 PM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] slur and @curvedir
>
> 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
>>
>>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l