[MEI-L] slur and @curvedir
Laurent Pugin
lxpugin at gmail.com
Mon Feb 16 23:38:14 CET 2015
Hi Perry,
Yes, this is what I had in mind. Even if turning this into bezier points is
not trivial, it would still be useful in some cases. Especially since, as
Don pointed out, there are other ways to generate curves.
Laurent
On Sat, Feb 14, 2015 at 1:07 AM, Roland, Perry D. (pdr4h) <
pdr4h at eservices.virginia.edu> wrote:
>
>
> I can’t be certain, but I think the attached (really, REALLY crude)
> illustration depicts what Laurent was getting at. Forgive me if I’ve
> gotten it wrong.
>
>
>
> The “crest” or “trough” of each undulation of the curve is specified by 2
> values: the point along an imaginary line connecting the end points of the
> curve to which the crest is perpendicular and the “height/depth” of the
> crest/trough. The distance from the imaginary line to the crest/trough of
> the curve is expressed in units allowed by data.MEASUREMENT
> (cm|mm|in|pt|pc|vu) with ‘vu’ being the default. Negative values indicate
> curvature to the right of the imaginary line (a trough), positive values to
> the left (a crest). The point along the imaginary line where the
> crest/trough occurs is expressed as a percentage of the length of the line.
>
>
>
> In the first slur, the trough occurs at a point that is 25% of the
> distance between the line’s end points with a “depth” of -2. The crest
> occurs at 85% of the length of the line with a “height” of 2.
>
>
>
> In the second slur, the troughs and crests occur at 15%, 45%, 75%, and 90%
> with heights and depths of -2, 2, -3, 2.
>
>
>
> I haven’t yet worked out the data model for a <slur> that behaves this
> way, but I believe mimicking the one I presented yesterday using Bezier
> curves is the right direction.
>
>
>
> My question at this point is, Is this a species of Bezier curve that could
> be accommodated using the <bezier> element introduced yesterday?
>
> For example --
>
>
>
> <!ELEMENT slur (bezier*)>
>
> <!ELEMENT bezier (bp+)>
>
> <!ELEMENT bp EMPTY>
>
> <!ATTLIST bp
>
> rise decimal REQUIRED
>
> run decimal REQUIRED>
>
>
>
> where @rise = height/depth of the crest/trough and @run = distance along
> the imaginary line. What isn’t addressed here yet is the specification of
> the end points of the curve. Perhaps @anchor1 and @anchor2 or @startid and
> @endid?
>
>
>
> You may ask why is this needed. As I’ve said before, Bezier curves are
> fine if you’re working in a GUI environment, but if not then this provides
> a convenient way of specifying the curve that can be accomplished in a text
> editor.
>
>
>
> --
>
> p.
>
>
>
>
>
> *From:* Laurent Pugin [mailto:lxpugin at gmail.com]
> *Sent:* Tuesday, February 03, 2015 10:06 AM
> *To:* Roland, Perry D. (pdr4h)
> *Cc:* Music Encoding Initiative
>
> *Subject:* Re: [MEI-L] slur and @curvedir
>
>
>
> 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/20150216/7e2cb744/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/20150216/7e2cb744/attachment.png>
More information about the mei-l
mailing list