Re: tuplet slurs
On 12-2-2017 21:45, David Nalesnik wrote: Unfortunately, I am once again unable to get a patch successfully loaded with git-cl. I seem to lose my connection with codereview.appspot.com before all the base files can be loaded. I tried to keep the patch short by leaving documentation out, but it's failed several times. A Rietveld issue is created (https://codereview.appspot.com/320190043/), but the base file of scm/define-grobs.scm fails to load, leading to "error: old chunk mismatch" in the diff. No tracker issue gets created. (This was the topic of a recent thread on -devel: http://www.mail-archive.com/lilypond-devel@gnu.org/msg65813.html. Ultimately, I had to get the patch shepherded by Harm.) If you or anybody has any idea how I could fix this, please let me know. I assume it's something to do with VirtualBox and my Win10 system. Thanks, David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user Will this functionality (eventually) be available in 'standard' Lilypond? Or should I learn how to build Lilypond myself to be able to use the tuplet slurs? I checked 2.1.9.59 and it doesnt seem to be available yet. Regard, Auke ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplet slurs
On Mon, Apr 17, 2017 at 2:05 AM, Partitura Organum wrote: > > On 12-2-2017 21:45, David Nalesnik wrote: >> >> >> Unfortunately, I am once again unable to get a patch successfully >> loaded with git-cl. >> >> I seem to lose my connection with codereview.appspot.com before all >> the base files can be loaded. >> >> I tried to keep the patch short by leaving documentation out, but it's >> failed several times. A Rietveld issue is created >> (https://codereview.appspot.com/320190043/), but the base file of >> scm/define-grobs.scm fails to load, leading to "error: old chunk >> mismatch" in the diff. No tracker issue gets created. >> >> (This was the topic of a recent thread on -devel: >> http://www.mail-archive.com/lilypond-devel@gnu.org/msg65813.html. >> Ultimately, I had to get the patch shepherded by Harm.) >> >> If you or anybody has any idea how I could fix this, please let me >> know. I assume it's something to do with VirtualBox and my Win10 >> system. >> >> Thanks, >> David >> >> ___ >> lilypond-user mailing list >> lilypond-user@gnu.org >> https://lists.gnu.org/mailman/listinfo/lilypond-user > > > Will this functionality (eventually) be available in 'standard' Lilypond? Or > should I learn how to build Lilypond myself to be able to use the tuplet > slurs? > I checked 2.1.9.59 and it doesnt seem to be available yet. > The goal would be to have it in LilyPond, of course. My reason for not putting this forward (now that I've found a way past the problem mentioned in the quote) is that it's a stub, a sketch, more suited to "unstable" releases than the impending 2.20 release. I should probably hold off until there's a clear separation between material destined for 2.20 and ongoing development. (I don't know anything about a timetable.) I alluded to a revised patch above. I could post it so the code would be available, though you would of course need to build LilyPond to use it. (In my experience, it's no big deal to set up and use LilyDev.) -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplet slurs
On 17-4-2017 16:04, David Nalesnik wrote: The goal would be to have it in LilyPond, of course. My reason for not putting this forward (now that I've found a way past the problem mentioned in the quote) is that it's a stub, a sketch, more suited to "unstable" releases than the impending 2.20 release. I should probably hold off until there's a clear separation between material destined for 2.20 and ongoing development. (I don't know anything about a timetable.) I alluded to a revised patch above. I could post it so the code would be available, though you would of course need to build LilyPond to use it. (In my experience, it's no big deal to set up and use LilyDev.) -David Thanks for the answer. Than I should probably learn to build Lilypond from source myself. The tuplet slurs fit the music I'm engraving (baroque organ music) better than the default 'hooks'. Learning how to compile Lilypond is probably an inevitable step for anyone who uses Lilypond for several years... Regards, Auke ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplet slurs
On 09/02/17 18:53, Werner LEMBERG wrote: > > For voices with lyrics it is common to put triplet indications always > above the staff, using the following rules. > >. stems up or down, no beam: as usual (i.e., a number and a bracket > at the top, as if using \tupletUp) > >. stems up, with beam: as usual (i.e., a number over the beam) > > The last case, however, is unusual: > >. stem down, with beam: a number and a *slur* at the top. > > I would like to have a single command that makes lilypond do that > automatically. Has this been requested before? A quick searched > yielded nothing. See my "Triplets" thread started 14/01/17 18:14. In the end I gave up and used the Lilypond standard in the interests of speed. > Hopefully, the attached images makes everything clear (note that I > don't need full brackets). > > > Werner signature.asc Description: OpenPGP digital signature ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplet slurs
Hi Werner, On Thu, Feb 9, 2017 at 12:53 PM, Werner LEMBERG wrote: > > For voices with lyrics it is common to put triplet indications always > above the staff, using the following rules. > >. stems up or down, no beam: as usual (i.e., a number and a bracket > at the top, as if using \tupletUp) > >. stems up, with beam: as usual (i.e., a number over the beam) > > The last case, however, is unusual: > >. stem down, with beam: a number and a *slur* at the top. > > I would like to have a single command that makes lilypond do that > automatically. Has this been requested before? A quick searched > yielded nothing. > > Hopefully, the attached images makes everything clear (note that I > don't need full brackets). > It strikes me that I've seen code somewhere that uses slurs instead of brackets. I find this: http://www.lilypondforum.de/index.php?topic=1658.0 The results look great, but of course, the slur is broken. It might not be hard to modify that routine to do what you want.. How are you duplicating the other example, with an unbroken bracket? If you displace the TupletNumber in an ordinary bracket, the gap will remain. Is the bracket notation fairly common? I've certainly seen the slur-above notation. I'm asking because it might be fairly easy to modify the C++ TupletBracket stencil code to produce such slurs based on a context property. Also, a full bracket might be used if the tuplet number wouldn't intersect the bracket. Maybe this should be default behavior? I know I've seen the bracket notation in Britten, albeit without the tuplet number. David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplet slurs
On 11/02/17 00:18, David Nalesnik wrote: > Hi Werner, > > On Thu, Feb 9, 2017 at 12:53 PM, Werner LEMBERG wrote: >> >> For voices with lyrics it is common to put triplet indications always >> above the staff, using the following rules. >> >>. stems up or down, no beam: as usual (i.e., a number and a bracket >> at the top, as if using \tupletUp) >> >>. stems up, with beam: as usual (i.e., a number over the beam) >> >> The last case, however, is unusual: >> >>. stem down, with beam: a number and a *slur* at the top. >> >> I would like to have a single command that makes lilypond do that >> automatically. Has this been requested before? A quick searched >> yielded nothing. >> >> Hopefully, the attached images makes everything clear (note that I >> don't need full brackets). >> > > It strikes me that I've seen code somewhere that uses slurs instead of > brackets. I find this: > http://www.lilypondforum.de/index.php?topic=1658.0 > > The results look great, but of course, the slur is broken. It might > not be hard to modify that routine to do what you want.. > > How are you duplicating the other example, with an unbroken bracket? > If you displace the TupletNumber in an ordinary bracket, the gap will > remain. > > Is the bracket notation fairly common? I've certainly seen the > slur-above notation. > > I'm asking because it might be fairly easy to modify the C++ > TupletBracket stencil code to produce such slurs based on a context > property. > > Also, a full bracket might be used if the tuplet number wouldn't > intersect the bracket. Maybe this should be default behavior? I know > I've seen the bracket notation in Britten, albeit without the tuplet > number. > > David > I've just had another look at the "Rudiments & Theory of Music" by the Associated Board of the Royal Schools of Music. Triplets are introduced in Grade II (section 26 in my 1958 edition) and are shown without brackets or slurs, just a number, when the quavers are beamed together. Later in the same section crotchets are shown with a slur. However when explaining trills (Grade V, section 29a) the triplet on demisemiquavers is shown with a slur as well as being beamed. I suspect that this is either a US/UK issue, or else the use of brackets is a more recent style, or possibly both! Certainly 19thC music published in the UK seems to favour slur-type triplets. Martin signature.asc Description: OpenPGP digital signature ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplet slurs
On 11/02/17 10:42, J Martin Rushton wrote: > On 11/02/17 00:18, David Nalesnik wrote: >> Hi Werner, >> >> On Thu, Feb 9, 2017 at 12:53 PM, Werner LEMBERG wrote: >>> >>> For voices with lyrics it is common to put triplet indications always >>> above the staff, using the following rules. >>> >>>. stems up or down, no beam: as usual (i.e., a number and a bracket >>> at the top, as if using \tupletUp) >>> >>>. stems up, with beam: as usual (i.e., a number over the beam) >>> >>> The last case, however, is unusual: >>> >>>. stem down, with beam: a number and a *slur* at the top. >>> >>> I would like to have a single command that makes lilypond do that >>> automatically. Has this been requested before? A quick searched >>> yielded nothing. >>> >>> Hopefully, the attached images makes everything clear (note that I >>> don't need full brackets). >>> >> >> It strikes me that I've seen code somewhere that uses slurs instead of >> brackets. I find this: >> http://www.lilypondforum.de/index.php?topic=1658.0 >> >> The results look great, but of course, the slur is broken. It might >> not be hard to modify that routine to do what you want.. >> >> How are you duplicating the other example, with an unbroken bracket? >> If you displace the TupletNumber in an ordinary bracket, the gap will >> remain. >> >> Is the bracket notation fairly common? I've certainly seen the >> slur-above notation. >> >> I'm asking because it might be fairly easy to modify the C++ >> TupletBracket stencil code to produce such slurs based on a context >> property. >> >> Also, a full bracket might be used if the tuplet number wouldn't >> intersect the bracket. Maybe this should be default behavior? I know >> I've seen the bracket notation in Britten, albeit without the tuplet >> number. >> >> David >> > I've just had another look at the "Rudiments & Theory of Music" by the > Associated Board of the Royal Schools of Music. Triplets are introduced > in Grade II (section 26 in my 1958 edition) and are shown without > brackets or slurs, just a number, when the quavers are beamed together. > Later in the same section crotchets are shown with a slur. However when > explaining trills (Grade V, section 29a) the triplet on demisemiquavers > is shown with a slur as well as being beamed. > > I suspect that this is either a US/UK issue, or else the use of brackets > is a more recent style, or possibly both! Certainly 19thC music > published in the UK seems to favour slur-type triplets. > > Martin > I've dug out "The AB Guide to Music Theory", also published by the ABRSM, but dated 1989 and last printed in 2012. The key phrase is "and sometimes a curved line or square bracket is added" (Grade III section 3). Both examples are shown, though in the rest of the book there is a tendency to use the square form. Martin signature.asc Description: OpenPGP digital signature ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplet slurs
>> For voices with lyrics it is common to put triplet indications >> always above the staff, using the following rules. >> >> . stems up or down, no beam: as usual (i.e., a number and a >> bracket at the top, as if using \tupletUp) >> >>. stems up, with beam: as usual (i.e., a number over the beam) >> >> The last case, however, is unusual: >> >>. stem down, with beam: a number and a *slur* at the top. BTW, these rules can be found in the vocal score of `Arabella' (by Richard Strauss), for example. > It strikes me that I've seen code somewhere that uses slurs instead of > brackets. I find this: > http://www.lilypondforum.de/index.php?topic=1658.0 Yes, I can remember that also – very nice! > The results look great, but of course, the slur is broken. It might > not be hard to modify that routine to do what you want.. Oh, I actually don't really care whether the slur is broken or not. I'm rather interested in having a lilypond option to make it behave (i.e., differentiate between tuplet slur and tuplet brackets) as outlined above. > [...] Also, a full bracket might be used if the tuplet number > wouldn't intersect the bracket. Maybe this should be default > behavior? I know I've seen the bracket notation in Britten, albeit > without the tuplet number. I think making lilypond provide unbroken tuplet slurs and brackets is a welcome addition :-) Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplet slurs
On Sat, Feb 11, 2017 at 11:11 AM, Werner LEMBERG wrote:
>
>>> For voices with lyrics it is common to put triplet indications
>>> always above the staff, using the following rules.
>>>
>>> . stems up or down, no beam: as usual (i.e., a number and a
>>> bracket at the top, as if using \tupletUp)
>>>
>>>. stems up, with beam: as usual (i.e., a number over the beam)
>>>
>>> The last case, however, is unusual:
>>>
>>>. stem down, with beam: a number and a *slur* at the top.
>
> BTW, these rules can be found in the vocal score of `Arabella' (by
> Richard Strauss), for example.
>
>> It strikes me that I've seen code somewhere that uses slurs instead of
>> brackets. I find this:
>> http://www.lilypondforum.de/index.php?topic=1658.0
>
> Yes, I can remember that also – very nice!
>
>> The results look great, but of course, the slur is broken. It might
>> not be hard to modify that routine to do what you want..
>
> Oh, I actually don't really care whether the slur is broken or not.
> I'm rather interested in having a lilypond option to make it behave
> (i.e., differentiate between tuplet slur and tuplet brackets) as
> outlined above.
I've attached a patch which permits tuplets with slurs instead of
brackets. Sorry that you have to build LilyPond to use it.
It's pretty rough. For one thing, the slur shapes for inclined slurs
are probably not ideal.
To get the bowed-tuplets, you set TupletBracket.tuplet-slur to #t.
You can move the slur closer/further from the number by setting
TupletNumber.padding to the value you'd like (default: 0.3). Don't
know what other
consequences there might be when setting TupletNumber.padding, but I
don't want to add more properties unless it's really necessary.
To get the behavior you want, check the example file. There is a
Scheme function which
should put your rules into effect.
>
>> [...] Also, a full bracket might be used if the tuplet number
>> wouldn't intersect the bracket. Maybe this should be default
>> behavior? I know I've seen the bracket notation in Britten, albeit
>> without the tuplet number.
>
> I think making lilypond provide unbroken tuplet slurs and brackets is
> a welcome addition :-)
I'll look at this too. Shouldn't be too hard.
Best,
David
From 79fe76eaf0fa518c2b6d466ec9e889b820bb9e16 Mon Sep 17 00:00:00 2001
From: David Nalesnik
Date: Sat, 11 Feb 2017 13:19:16 -0600
Subject: [PATCH] Allow slurs instead of brackets with tuplets
Older editions often use slurs with tuplets. This patch
creates a new property ('tuplet-slur'), which toggles this
notation style. Note that 'bracket-visibility must be set
to #t for the slurs to appear with beamed notes.
(In the future, 'bracket-visibility might automatically be set
to #t.)
---
lily/tuplet-bracket.cc | 73 --
scm/define-grob-properties.scm | 2 ++
scm/define-grobs.scm | 1 +
3 files changed, 66 insertions(+), 10 deletions(-)
diff --git a/lily/tuplet-bracket.cc b/lily/tuplet-bracket.cc
index 340b017..5a7dc86 100644
--- a/lily/tuplet-bracket.cc
+++ b/lily/tuplet-bracket.cc
@@ -58,6 +58,7 @@
#include "lookup.hh"
#include "paper-column.hh"
#include "moment.hh"
+#include "bezier.hh"
static Item *
get_x_bound_item (Grob *me_grob, Direction hdir, Direction my_dir)
@@ -245,6 +246,48 @@ Tuplet_bracket::calc_x_positions (SCM smob)
return ly_interval2scm (x_span - me->get_bound (LEFT)->relative_coordinate (commonx, X_AXIS));
}
+Bezier
+tuplet_slur_shape (Offset l, Offset r, Real h_limit, Real ratio, Direction d)
+{
+ Real indent;
+ Real height;
+
+ Real width = (r[X_AXIS] - l[X_AXIS]);
+
+ get_slur_indent_height (&indent, &height, width, h_limit, ratio);
+
+ Bezier curve;
+
+ curve.control_[0] = l;
+ curve.control_[1] = Offset (l[X_AXIS] + indent, l[Y_AXIS] + height * d);
+ curve.control_[2] = Offset (r[X_AXIS] - indent, r[Y_AXIS] + height * d);
+ curve.control_[3] = r;
+
+ return curve;
+}
+
+Stencil
+make_tuplet_slur (Grob *me, Offset l, Offset r)
+{
+ SCM dash_definition = me->get_property ("dash-definition");
+ Real lt = me->layout ()->get_dimension (ly_symbol2scm ("line-thickness"));
+
+ Real height_limit = 1.5;
+ Real ratio = .33;
+
+ Direction dir = get_grob_direction (me);
+
+ Bezier curve = tuplet_slur_shape (l, r, height_limit, ratio, dir);
+
+ Stencil mol (Lookup::slur (curve, lt, lt, dash_definition));
+
+ Grob *tn = unsmob (me->get_object ("tuplet-number"));
+ Real padding = robust_scm2double (tn->get_property ("padding"), 0.3);
+
+ mol.translate_axis (padding * dir, Y_AXIS);
+ return mol;
+}
+
/*
TODO:
@@ -258,6 +301,8 @@ Tuplet_bracket::print (SCM smob)
Spanner *me = unsmob (smob);
Stencil mol;
+ bool tuplet_slur = ly_scm2bool (me->get_property ("tuplet-slur"));
+
extract_grob_set (me, "note-columns", columns);
bool equally_long = false;
Grob *par_beam = parallel_beam (me, columns, &equally_long);
@@ -373,15 +418,19 @@ Tuplet_bracket::print (SCM smob)
}
Re: tuplet slurs
On Sat, Feb 11, 2017 at 1:43 PM, David Nalesnik wrote: > On Sat, Feb 11, 2017 at 11:11 AM, Werner LEMBERG wrote: >> For voices with lyrics it is common to put triplet indications always above the staff, using the following rules. . stems up or down, no beam: as usual (i.e., a number and a bracket at the top, as if using \tupletUp) . stems up, with beam: as usual (i.e., a number over the beam) The last case, however, is unusual: . stem down, with beam: a number and a *slur* at the top. >> >> BTW, these rules can be found in the vocal score of `Arabella' (by >> Richard Strauss), for example. >> >>> It strikes me that I've seen code somewhere that uses slurs instead of >>> brackets. I find this: >>> http://www.lilypondforum.de/index.php?topic=1658.0 >> >> Yes, I can remember that also – very nice! >> >>> The results look great, but of course, the slur is broken. It might >>> not be hard to modify that routine to do what you want.. >> >> Oh, I actually don't really care whether the slur is broken or not. >> I'm rather interested in having a lilypond option to make it behave >> (i.e., differentiate between tuplet slur and tuplet brackets) as >> outlined above. > > I've attached a patch which permits tuplets with slurs instead of > brackets. Sorry that you have to build LilyPond to use it. > > It's pretty rough. For one thing, the slur shapes for inclined slurs > are probably not ideal. > > To get the bowed-tuplets, you set TupletBracket.tuplet-slur to #t. > > You can move the slur closer/further from the number by setting > TupletNumber.padding to the value you'd like (default: 0.3). Don't > know what other > consequences there might be when setting TupletNumber.padding, but I > don't want to add more properties unless it's really necessary. > > To get the behavior you want, check the example file. There is a > Scheme function which > should put your rules into effect. > Here's an image of the example file. David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplet slurs
On Sat, Feb 11, 2017 at 1:47 PM, David Nalesnik
wrote:
> On Sat, Feb 11, 2017 at 1:43 PM, David Nalesnik
> wrote:
>> On Sat, Feb 11, 2017 at 11:11 AM, Werner LEMBERG wrote:
>>>
> For voices with lyrics it is common to put triplet indications
> always above the staff, using the following rules.
>
> . stems up or down, no beam: as usual (i.e., a number and a
> bracket at the top, as if using \tupletUp)
>
>. stems up, with beam: as usual (i.e., a number over the beam)
>
> The last case, however, is unusual:
>
>. stem down, with beam: a number and a *slur* at the top.
>>>
>>> BTW, these rules can be found in the vocal score of `Arabella' (by
>>> Richard Strauss), for example.
>>>
It strikes me that I've seen code somewhere that uses slurs instead of
brackets. I find this:
http://www.lilypondforum.de/index.php?topic=1658.0
>>>
>>> Yes, I can remember that also – very nice!
>>>
The results look great, but of course, the slur is broken. It might
not be hard to modify that routine to do what you want..
>>>
>>> Oh, I actually don't really care whether the slur is broken or not.
>>> I'm rather interested in having a lilypond option to make it behave
>>> (i.e., differentiate between tuplet slur and tuplet brackets) as
>>> outlined above.
>>
>> I've attached a patch which permits tuplets with slurs instead of
>> brackets. Sorry that you have to build LilyPond to use it.
>>
>> It's pretty rough. For one thing, the slur shapes for inclined slurs
>> are probably not ideal.
>>
>> To get the bowed-tuplets, you set TupletBracket.tuplet-slur to #t.
>>
>> You can move the slur closer/further from the number by setting
>> TupletNumber.padding to the value you'd like (default: 0.3). Don't
>> know what other
>> consequences there might be when setting TupletNumber.padding, but I
>> don't want to add more properties unless it's really necessary.
>>
>> To get the behavior you want, check the example file. There is a
>> Scheme function which
>> should put your rules into effect.
>>
The attached is better structured and it supports 'shorten-pair for the slurs.
(Note that you can also set dash-definition)
David
From c583d664d2aed5f62cb603dfbb01235ecd2cbd23 Mon Sep 17 00:00:00 2001
From: David Nalesnik
Date: Sat, 11 Feb 2017 13:19:16 -0600
Subject: [PATCH] Allow slurs instead of brackets with tuplets
Older editions often use slurs with tuplets. This patch
creates a new property ('tuplet-slur'), which toggles this
notation style. Note that 'bracket-visibility must be set
to #t for the slurs to appear with beamed notes.
(In the future, 'bracket-visibility might automatically be set
to #t.)
Support shorten-pair
---
lily/tuplet-bracket.cc | 95 +++---
scm/define-grob-properties.scm | 2 +
scm/define-grobs.scm | 1 +
3 files changed, 83 insertions(+), 15 deletions(-)
diff --git a/lily/tuplet-bracket.cc b/lily/tuplet-bracket.cc
index 340b017..2600d7a 100644
--- a/lily/tuplet-bracket.cc
+++ b/lily/tuplet-bracket.cc
@@ -58,6 +58,7 @@
#include "lookup.hh"
#include "paper-column.hh"
#include "moment.hh"
+#include "bezier.hh"
static Item *
get_x_bound_item (Grob *me_grob, Direction hdir, Direction my_dir)
@@ -245,6 +246,54 @@ Tuplet_bracket::calc_x_positions (SCM smob)
return ly_interval2scm (x_span - me->get_bound (LEFT)->relative_coordinate (commonx, X_AXIS));
}
+Bezier
+tuplet_slur_shape (Offset l, Offset r, Real h_limit, Real ratio, Direction d)
+{
+ Real indent;
+ Real height;
+
+ Real width = (r[X_AXIS] - l[X_AXIS]);
+
+ get_slur_indent_height (&indent, &height, width, h_limit, ratio);
+
+ Bezier curve;
+
+ curve.control_[0] = l;
+ curve.control_[1] = Offset (l[X_AXIS] + indent, l[Y_AXIS] + height * d);
+ curve.control_[2] = Offset (r[X_AXIS] - indent, r[Y_AXIS] + height * d);
+ curve.control_[3] = r;
+
+ return curve;
+}
+
+Stencil
+make_tuplet_slur (Grob *me, Offset l, Offset r, Drul_array shorten)
+{
+ SCM dash_definition = me->get_property ("dash-definition");
+ Real lt = me->layout ()->get_dimension (ly_symbol2scm ("line-thickness"));
+
+ Real height_limit = 1.5;
+ Real ratio = .33;
+
+ Direction dir = get_grob_direction (me);
+
+ Offset dz = r - l;
+ Real length = dz.length ();
+
+ l += shorten[LEFT] / length * dz;
+ r -= shorten[RIGHT] / length * dz;
+
+ Bezier curve = tuplet_slur_shape (l, r, height_limit, ratio, dir);
+
+ Stencil mol (Lookup::slur (curve, lt, lt, dash_definition));
+
+ Grob *tn = unsmob (me->get_object ("tuplet-number"));
+ Real padding = robust_scm2double (tn->get_property ("padding"), 0.3);
+
+ mol.translate_axis (padding * dir, Y_AXIS);
+ return mol;
+}
+
/*
TODO:
@@ -258,6 +307,8 @@ Tuplet_bracket::print (SCM smob)
Spanner *me = unsmob (smob);
Stencil mol;
+ bool tuplet_slur = ly_scm2bool (me->get_property ("tuplet-slur"));
+
extract_grob_set (me, "note-columns", columns);
bool equally_long = fa
Re: tuplet slurs
Hi David, I think this would make a great addition to the code base, regardless of how perfect the bezier shapes are. One could file an issue for improving that. I’d say: Please propose a patch. Best, Simon ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplet slurs
> The attached is better structured and it supports 'shorten-pair for > the slurs. Very nice! Please submit this :-) Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplet slurs
On Sun, Feb 12, 2017 at 11:52 AM, Werner LEMBERG wrote: > >> The attached is better structured and it supports 'shorten-pair for >> the slurs. > > Very nice! Please submit this :-) Will do, just need to clean it up a little. In the meantime, I've improved the slur shapes since the last patch. Basically, I think they should be simple bows, rotated to the angle of a bracket. Best, David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplet slurs
On Sun, Feb 12, 2017 at 12:00 PM, David Nalesnik wrote: > On Sun, Feb 12, 2017 at 11:52 AM, Werner LEMBERG wrote: >> >>> The attached is better structured and it supports 'shorten-pair for >>> the slurs. >> >> Very nice! Please submit this :-) > > > Will do, just need to clean it up a little. In the meantime, I've > improved the slur shapes since the last patch. Basically, I think > they should be simple bows, rotated to the angle of a bracket. > Unfortunately, I am once again unable to get a patch successfully loaded with git-cl. I seem to lose my connection with codereview.appspot.com before all the base files can be loaded. I tried to keep the patch short by leaving documentation out, but it's failed several times. A Rietveld issue is created (https://codereview.appspot.com/320190043/), but the base file of scm/define-grobs.scm fails to load, leading to "error: old chunk mismatch" in the diff. No tracker issue gets created. (This was the topic of a recent thread on -devel: http://www.mail-archive.com/lilypond-devel@gnu.org/msg65813.html. Ultimately, I had to get the patch shepherded by Harm.) If you or anybody has any idea how I could fix this, please let me know. I assume it's something to do with VirtualBox and my Win10 system. Thanks, David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplet slurs
Am 11.02.2017 um 01:18 schrieb David Nalesnik: > Is the bracket notation fairly common? I've certainly seen the > slur-above notation. > I'm not sure if that adds something useful to that thread, but maybe one item where the community has seen this notation is https://www.musictypefoundry.com/wp-content/uploads/2016/05/haydn-sonata.png (from https://www.musictypefoundry.com/product/mtf-haydn/). I'd also very much like to see this option in LilyPond. Urs -- u...@openlilylib.org https://openlilylib.org http://lilypondblog.org ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
