lilypond-auto
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lilypond-auto] Issue 3115 in lilypond: Add convert-ly rule for beam


From: lilypond
Subject: Re: [Lilypond-auto] Issue 3115 in lilypond: Add convert-ly rule for beam-gap
Date: Mon, 30 Sep 2013 19:04:45 +0000


Comment #7 on issue 3115 by address@hidden: Add convert-ly rule for beam-gap
http://code.google.com/p/lilypond/issues/detail?id=3115

Maybe we are better off reverting that patch anyway. If you take a look at the following part of the patch:
+MAKE_SCHEME_CALLBACK (Beam, calc_beam_gap, 1);
+SCM
+Beam::calc_beam_gap (SCM smob)
+{
+ Spanner *me = unsmob_spanner (smob);
+ SCM default_value = scm_cons (scm_from_double (0.8), scm_from_double (0.8));
+ if (!whole_note_close_chord_tremolo (me))
+ return default_value;
+
+ Interval left = Paper_column::left_non_note_column_width
+ (me->get_bound (RIGHT)->get_column ());
+
+ if (left.length () > 0.4)
+ return scm_cons (scm_from_double (0.8), scm_from_double (1.3 + left.length ()));
+ else
+ return default_value;
+}

then it is clear that
a) 0.8 now is hardwired instead of overridable
b) if you override beam-gap, the logic for dealing with issue 704 is locked out and the collision avoidance for whole notes with chord tremolos is inactivated c) the code results in highly discontinuous behavior: when left.length passes 0.4, the second beam-gap value jumps from 0.8 to 1.7

In short: what this code does with the beam-gap does not make enough sense to keep it. It seems sanest to revert the patch and reopen issue 704. It's possible that parts of the patch and its underlying analysis can be turned into a good solution, but the beam-gap part of it does not appear tenable.

--
You received this message because this project is configured to send all issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings



reply via email to

[Prev in Thread] Current Thread [Next in Thread]