[MEI-L] slur and @curvedir

Tue Feb 3 16:05:30 CET 2015

Hi Perry,

One option I think could be interesting to add for providing more
flexibility is the possibility to specify the bezier points with a
percentage for the horizontal position of the intermediate points (0 to
100) and vertical units (as in @bulge) for vertical positions. This would
be much easier to draw on a black-board. I'll try to prepare a couple of
example images.

Laurent

PS For some reason, I have not received the messages from Axel and
Raffaele. Is anything wrong with my subscription to the list?

On Tue, Feb 3, 2015 at 3:50 PM, Roland, Perry D. (pdr4h) <
pdr4h at eservices.virginia.edu> wrote:

>  Hi Raffaele,
>
>  Using @bezier only "locks" the rendering if the control points are
> specified as absolute page coordinates.  If they're given as offsets from
> something else, such as a particular note, then the rendition of the slur
> is dependent on the position of that thing.
>
>  This is how I envision it working.  It's possible that moving the bezier
> control points (even if they're moved relative to everything else) will
> change the shape of the curve.  If that's true, then our only mechanism for
> controlling a slur is through the use of @bulge.  For automatic layout
> without any user intervention, the only mechanism is @curvedir --
> remembering that values in @curvedir cannot possibly result in a perfect
> rendition every time.  It seems there truly is no way to have the cake and
> eat it too, hence the comment which began my initial response to Benni.
>
>  Of course, only those with more knowledge and experience with this stuff
> can say for sure.
> Laurent?  Craig?  Zoltan?  Want to join in?
>
>  --
> 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
> Raffaele Viglianti [raffaeleviglianti at gmail.com]
> *Sent:* Tuesday, February 03, 2015 9:29 AM
> *To:* Music Encoding Initiative
> *Subject:* Re: [MEI-L] slur and @curvedir
>
>    Hi all,
>
>  I find Perry's explanation really helpful and interesting, particularly
> concerning the the sharing of responsibilities between the encoder and the
> renderer. Encoding @bezier before rendering locks the encoding into only
> one possible rendering, which is not great for the reflowing that a truly
> dynamic score should allow. Unless the aim of the encoder is to
> represent/document the curvature of one specific written source, which is a
> totally legitimate approach (and might be what Benni is after?).
>
>  Having two slurs and joining them, instead, seems conceptually wrong to
> me: there is only one slur and no real XML overlapping (or other
> limitation) that would justify, arguably, splitting the element in two.
>
>  Raff
>
> On Tue, Feb 3, 2015 at 5:27 AM, Axel Teich Geertinger <atge at kb.dk> wrote:
>
>>  Hi Perry
>>
>>
>>
>> Thanks for your elaborate reply. As always I wasn’t aware of any worms
>> involved, but I did realize that there is no single or easy answer :-)
>>
>>
>>
>> Drawing a complex slur that not only avoids collisions with other objects
>> but is also aesthetically satisfying can be quite a challenge. My deepest
>> respect for people working on rendering slurs!
>>
>> As you say, it almost always requires visual control and corrections to
>> get it right. But recording the corrections also means that they will have
>> to be encodable somehow, that is, in more detail than possible with
>> @bezier, for instance. I have no immediate ideas about how to solve this in
>> a medium as fluid as music notation.
>>
>>
>>
>> Best,
>>
>> Axel
>>
>>
>>
>> *Fra:* mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] *På vegne af *Roland,
>> Perry D. (pdr4h)
>> *Sendt:* 2. februar 2015 20:14
>>
>> *Til:* Music Encoding Initiative
>> *Emne:* Re: [MEI-L] slur and @curvedir
>>
>>
>>
>> Hi Axel,
>>
>>
>>
>> One comment before I answer your questions -- This is a huge can of worms
>> for which it seems there can never be a single, universally satisfying
>> answer.
>>
>>
>>
>> @curvedir only provides minimal information about the slur so a renderer
>> must "figure out" the rest. This is the easiest method for the encoder, but
>> requires a lot more intelligence on the part of the rendering engine, for
>> example with regard to collision avoidance. From another angle, however, it
>> provides the greatest amount of flexibility for the renderer to arrive at
>> the final shape of the slur.  Like I said before, aside from providing a
>> more detailed classification purpose, allowing curvdir="above below above
>> below (and so on)" doesn't really provide much rendering help because, just
>> as you've observed, it says nothing about the location of the points where
>> the slur is supposed to bend back on itself.
>>
>>
>>
>> @bulge attempts to provide this missing information by indicating
>> distance from an imaginary line between the end points of the slur.
>> Providing two values means the distance between the end points should be
>> halved and a curve drawn that passes through the starting point, the point
>> indicated by the 1st value in @bulge, the mid-point of the line, the point
>> indicated by the 2nd value, and the ending point.  Three values would mean
>> dividing the distance between the end points by thirds, etc.
>>
>>
>>
>> "Simple" slurs (i.e., ones that don't alternate sides of the imaginary
>> line) can be drawn with @bulge by supplying only a single value or by
>> giving only positive or only negative values.  Doing this, instead of using
>> @curvedir, places the shape of the slur in the control of the encoder
>> instead of the rendering engine, but puts the burden of "scribing" the
>> shape on the encoder.  The ability to draw "simple" slurs is why @bulge
>> can't be constrained to alternating positive and negative values.
>>
>>
>>
>> The example provided in the Guidelines should use the values -2 and 1.
>> The diagram is also misleading in that the lines connecting the curve with
>> the imaginary line should divide their respective sections of the curve
>> into equal parts; that is, the line illustrating point 1 should be drawn at
>> the "highest" point of the curve, mid-way between the mid-point of the
>> imaginary line and the end point of the slur.
>>
>>
>>
>> @bezier provides the most encoder control over the rendition of the
>> slur.  But unless the control points of the curve are expressed as offsets
>> from some musical feature (like a note, for instance), then re-flowing the
>> notation will "disconnect" the slur from it and the slur will end up in the
>> wrong place on the page.  So, the bezier control points have to be
>> *offsets* from something, presumably from the features pointed at by the
>> @startid and @endid attributes, as long as the notation is expected to be
>> "edit-able".  The @startid, @endid, @bezier combination will move the
>> slur with the notation.  The problem with bezier control points is the same
>> as with @bulge values -- it's nearly impossible for one to create them
>> without the aid of some kind of drawing environment or iterative
>> "code/view/code" workflow.
>>
>>
>>
>> Without a doubt, a better explanation of this stuff is desperately needed
>> the Guidelines. But, there may also be better ways of recording the
>> information necessary for drawing slurs than what is provided by the
>> current set of attributes.  I welcome contributions on either front.
>>
>>
>>
>> --
>>
>> 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 Axel
>> Teich Geertinger [atge at kb.dk]
>> *Sent:* Monday, February 02, 2015 3:29 AM
>> *To:* Music Encoding Initiative
>> *Subject:* Re: [MEI-L] slur and @curvedir
>>
>> 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
>> <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.
>>
>>
>>
>> [image: bildschirmfoto 2015-01-30 um 14 05 39]
>> <https://cloud.githubusercontent.com/assets/2430401/5976008/319371e8-a889-11e4-9a4c-7fe5cc246dfe.png>
>>
>> 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*
>> <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
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20150203/4334db23/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 69500 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20150203/4334db23/attachment.png>