[MEI-L] slur and @curvedir: exact control & joins

[Roland, Perry D. (pdr4h)]

Don's right -- this level of complexity of slurs can't be dealt with automatically.  Human intervention is required.  BUT, that intervention comes with a cost -- not unlike the case with Heisenberg uncertainty principle, one can't represent the Sorabji as a single entity and still have a high degree of control over its shape.  To have maximum control over the shape, the single slur (I presume it even continues on the next system/page) must be broken into at least two separate entities, each with their own set of control points.  I recognize that this is not ideal, but I believe it's the best that can be achieved at present. 

If multiple curves are used, are there mathematical functions / smoothing algorithms for "easing" one slur into another when they have a shared end/start point? 

Just for fun and/or extra credit, how would one handle this slur/these slurs in Finale, Sibelius, or (God help me asking) SCORE?

It  looks to me like the slur/slurs in the Sorabji example have actually been "drawn in" by hand, but it's pretty hard to do that with a digital file.  :-)  Well, unless you print it and then draw the slurs on the paper.  :-(

--
p.


> -----Original Message-----
> From: mei-l [mailto:mei-l-bounces+pdr4h=virginia.edu at lists.uni-
> paderborn.de] On Behalf Of Byrd, Donald A.
> Sent: Wednesday, February 11, 2015 4:05 PM
> To: Music Encoding Initiative
> Subject: Re: [MEI-L] slur and @curvedir: exact control & joins
> 
> Perry is right about the need, sometimes, for exact control of slur shape. I
> predict it'll be many years before any music rendering engine consistently
> does a really good job breaking slurs. What if the slur changes staff at the
> system break? Take a look at
> 
>     http://homes.soic.indiana.edu/donbyrd/InterestingMusicNotation.html
> 
> How well would any existing rendering engine determine shape
> automatically do with the Sorabji slur? That's a very extreme case, but in
> the (more reasonable) example from Ravel's Scarbo, how well would any
> rendering engine do automatically at the system break at the end of the
> example? Answer: Not well enough for, say, Barenreiter.
> 
> HOWEVER, it's also highly desirable that it be possible to encode slurs with
> multiple inflection points as single objects. Yes, you could encode them as
> separate curves that happen to coincide or overlap, but you'll never get the
> proper tapering at the joins that way.
> 
> --Don
> 
> 
> On Feb 11, 2015, at 10:53 AM, "Roland, Perry D. (pdr4h)"
> <pdr4h at eservices.virginia.edu> wrote:
> 
> >
> > Hi Axel,
> >
> > You’re absolutely right when you say that a rendering engine ought to be
> smart enough to intelligently break a slur across a system or page break.
> BUT, there might be situations where the software you’re using simply isn’t.
> Or where it wants to break the slur in a way that you feel isn’t exactly right.
> How can one “regain control” from the “rendering engine overlord” run
> amok?  One possibility is not give control to it in the first place; that is,
> specify *exactly* how you want the slur to be broken up by breaking it
> yourself and specifying where the pieces should be drawn.  Once you’ve
> done that, however, you want to leave a breadcrumb trail indicating how to
> get back to the generic single-slur state.  That’s the purpose of @join.
> >
> > Obviously, once you’ve split the slur, performing additional changes, such
> as moving the system or page break, means your carefully crafted slurs will
> be in the wrong place.  So, this procedure isn’t recommended for material
> that could change.  But it’s essential, I think, when you’ve placed everything
> “just so” (say for printing on paper) and you don’t want anything to move.
> In this case, MEI is functioning as an intermediate format for printing that
> comes at the end of processing chain.
> >
> > Bezier control points remove the need to specify the inflection points of a
> curve.  Moving the control points also moves the inflection points.  Using
> Bezier curves is more efficient, hence their adoption in a lot of graphical
> editing environments
> >
> > @bulge already does something similar to what you’re suggesting, but by
> specifying the points at which the curve “crests”, rather than where it
> changes direction.  I admit it’s a fairly blunt instrument, but sometimes
> that’s all that’s required.  The bulge concept is borrowed from Mup, which
> aims to achieve what I’d call “pass-able” rendering more-or-less
> automatically without a lot of user input.  @bulge gives a moderate amount
> of control over the shape of the curve without the aid of a GUI
> environment.  It’s in the middle of the continuum of control from “fully
> automatic” (<slur tstamp=”1” tstamp2=”3”/>) to “fully user-controlled”
> (<slur startid=”n1” endid=”n2” bezier=”x,y x1,y1”/>).  Which is also a
> continuum from “most flexible” to “most stable/fixed”.  J
> >
> > --
> > p.
> >
> >
> >
> > From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of
> Axel Teich Geertinger
> > Sent: Wednesday, February 11, 2015 3:54 AM
> > To: Music Encoding Initiative
> > Subject: Re: [MEI-L] slur and @curvedir
> >
> > There is something that has been puzzling me: I don’t think I have
> completely grasped the idea of @join when used with slurs (I haven’t really
> thought about other uses, though). It seems to me to be redundant. In
> which situation would it be necessary to explicitly encode that a slur needs
> to be interrupted at a system break? Doesn’t the system break itself provide
> all information necessary, leaving the actual division into two half-slurs to
> the rendering engine? Is there any thinkable situation where an encoded
> <sb> or an automatically generated system break would not imply the
> splitting of the slur at that point? Or the other way around: would it be
> necessary to split one (that is, logically one) slur into two (that is,
> graphically two) parts in any other situation?
> >
> > On editing or rendering a score (not necessarily following the exact layout
> of a particular source), the system break may change position. I that case, I
> would even have to update the endpoint of the first and the starting point
> of the second (half-)slur, right? What is the benefit from this operation?
> >
> > I agree with Zoltan that a slur should be encoded as one element, even
> when it has to be rendered as two distinct graphical objects _in some
> situations_. It makes me wonder whether an attribute like @join would be
> more useful to indicate the location of the points where a complex slur
> changes direction of bending (the joints, in terms of joined slurs with
> alternating curve direction).
> >
> > Best,
> > Axel
> >
> > Fra: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] På vegne af
> Roland, Perry D. (pdr4h)
> > Sendt: 10. februar 2015 22:16
> > Til: Music Encoding Initiative
> > Cc: zoltan.komives at gmail.com
> > Emne: Re: [MEI-L] slur and @curvedir
> >
> >
> > There’s no single answer to this. Whether one chooses to encode a single
> slur or chooses to create two depends on the purpose for the encoding -- a
> single slur is better for analytical purposes, but two may be better for
> rendering.  To fit both simultaneously, one can use <choice>, for example --
> >
> > <choice>
> >   <orig>
> >   <!-- single slur -->
> >     <slur tstamp="1" tstamp2="2m+1"/>
> >   </orig>
> >   <reg>
> >      <!-- multiple slurs, likely with additional rendering info provided in
> @bulge,
> >            @bezier, etc. -->
> >     <slur tstamp="1" tstamp2="1m+3"/>
> >     <slur tstamp="0" tstamp2="1"/>
> >   </reg>
> > </choice>
> >
> > The @join attribute on slur exists to indicate that multiple slurs are
> conceptually one, not to provide rendering info.
> >
> > I contend that @curvedir *can* provide a so-called “rendering hint”, but I
> agree that the rendering engine has to be pretty intelligent to make use of it
> -- Mup seems to do a reasonable job with only this much information.  I
> have no problem extending the values permitted in @curvedir, but I think
> over-specification there is not likely to be of much help.  A value of
> “complex” is about as far as I think we can go down that path.
> >
> > --
> > p.
> >
> >
> > From: Kőmíves Zoltán [mailto:zolaemil at gmail.com]
> > Sent: Tuesday, February 10, 2015 1:30 PM
> > To: Music Encoding Initiative
> > Cc: Roland, Perry D. (pdr4h)
> > Subject: Re: [MEI-L] slur and @curvedir
> >
> > Hi Perry,
> >
> > 1.
> > >[Raff]: 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.
> > *I agree. The proposed solutions of joining or splitting them makes
> complete sense when one need to render them.
> >
> > 2. As Laurent points out, relative positioning of the bezier points (end
> points being relative, say, to the starting and ending note heads, the control
> points being relative to these points) results in a "reflowable" slur - bezier
> curves stretch very nicely, maintaining their shape. However, it only helps as
> long as the slur isn't broken by a system break... In which case no single
> bezier will describe how to draw two curves.
> >
> > Talking about which, consider the attached example. How would you
> encode the pharse/slur mark starting at figure 9? I think one fairly natural
> encoding is <slur tstamp="1" tstamp2="2m+1"/>, but I can see how one
> could argue that splitting it into two slur elements are equally valid:
> > <slur tstamp="1" tstamp2="1m+3"/>
> > and in the first measure of the following system after figure 9:
> > <slur tstamp="0" tstamp2="1"/> (even though I would not encourage the
> use of tstamp values less than 1. I'm sure there's a better way of encoding of
> the starting point of the second slur!)
> >
> > I personally feel that encoding the slur as one element is better, even if
> there are two graphical objects that represent it. (Following this logic,
> whenever possible, I would probably try to avoid splitting measures into
> when the system breaks in the middle of the measure, even if it makes life a
> little harder when processing.)
> >
> > 3.
> > >[Perry]: For automatic layout without any user intervention, the only
> mechanism is @curvedir
> > * Given the difficulties, it seems to me that @curvedir alone does not
> provide sufficient control over curvature for truly automated rendering of
> slurs, even in the simpler cases. Furthermore, seeing the number of issues
> arising as soon as we mention @bezier, @bulge or curvature in general, I
> would say that a pure _classification_ mechanism would be useful. Perhaps
> this is a bit of a conceptual change, but maybe @curvedir could be regarded
> as such a classification (and extend its values to cover s-shaped and perhaps
> even more craziness)? Or perhaps a new attribute would fit the job better?
> >
> > Best
> > Zoltan
> >
> > 2015-02-03 15:05 GMT+00:00 Laurent Pugin <lxpugin at gmail.com>:
> > 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
> afRoland, 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] 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.
> >
> >
> > <image001.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 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
> >
> >
> 
> ---
> Donald Byrd
> Woodrow Wilson Indiana Teaching Fellow
> Adjunct Associate Professor of Informatics
> Visiting Scientist, Research Technologies
> Indiana University Bloomington
> 
> 
> 
> 
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l