[MEI-L] slur and @curvedir

Tue Feb 3 15:29:07 CET 2015

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/22ce6339/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/22ce6339/attachment.png>