Re: Inconsistent tuplet-number-kneed-beam-horizontal-fit.ly results?

David Nalesnik wrote: > I wonder if what you're seeing related to an issue with > the tuplet number code for which I just submitted a patch. (It fixes a > problem with faulty recognition of kneed beams in connection with overrides > of Beam.positions.) The patch doesn't change this. Making the b

Re: Difference between # and $

Urs Liska writes: > Hi, > > I have a hard time to understand the difference between # and $ in > LilyPond code blocks within Scheme functions. Same as elsewhere. Please read http://lilypond.org/doc/v2.19/Documentation/extending/lilypond-scheme-syntax> > 2.2.1 of the Extending manual says: > "

Difference between # and $

Hi, I have a hard time to understand the difference between # and $ in LilyPond code blocks within Scheme functions. 2.2.1 of the Extending manual says: "Within LilyPond code blocks, use # to reference function arguments (eg., ‘#arg1’) or to start an inline Scheme expression containing funct

Bad positioning of tuplet numbers on kneed beams with Beam.positions override. (issue 81330046)

Reviewers: , Message: Please review. Thanks! Description: Bad positioning of tuplet numbers on kneed beams with Beam.positions override. Previously, when Beam.positions was overridden, tuplet numbers on kneed beams would automatically be placed according to the bracket instead of against the b

Re: Inconsistent tuplet-number-kneed-beam-horizontal-fit.ly results?

Hi Devon, On Fri, Mar 28, 2014 at 3:47 PM, Devon Schudy wrote: > I'm getting unpredictable output from > input/regression/tuplet-number-kneed-beam-horizontal-fit.ly. > > Sometimes the second tuplet number is in bracket position below the > staff, and sometimes it overlaps the beam. When I run th

Re: Count MIDI ticks from the beginning of the score, not each staff independently. (issue 73610044)

On 2014/03/29 00:44:17, Devon Schudy wrote: dak wrote: > If not (I actually don't know), it seems like making it rather part of > the midi block might be more appropriate. In which case we would not > need to store it separately as it would then be part of > performance_->midi_. Oh, ye

PATCHES: Countdown for April 1 -0 06:00 GMT

Hello, 3888