Re: Tweaking Hairpin shape

[David Nalesnik]

Hi Stefano,

On Sun, Feb 11, 2018 at 3:44 PM, Stefano Troncaro
 wrote:
> I managed to fix it. The problem was not with the calculation of the angle,
> it was with the translation of the angle to the offset that the function
> applies to the vertical placement of the end-points of the hairpins. It is
> correct now.
>
> I also got rid of the rotation of the stencil for the case where the
> straight end-points are not needed, the coordinates of the end-points for
> the different cases are all calculated now.
>
> As far as I can tell this is done. Finally!
>
> I got the alists working now. I can't reproduce the problems I had earlier,
> and the error message was weird and I don't remember it. But I guess that's
> not important anymore.
>
> I'm not sure I understood the following:
>>
>> But the spanner is cloned for each broken segment, so you aren't
>> actually comparing
>> with the initial bit.  Each new segment is simply drawn with a stencil
>> reflecting its
>> position within the whole.
>
>
> By reading the code that creates the hairpin stencils I got the idea that
> after line breaks are calculated, hairpins get broken into smaller hairpins
> that are related to each other. And when drawing the stencils, if these
> relationships are found, then they are drawn differently (they can start and
> end in 1/3rd or 2/3rds of the height depending on the situation). If what
> I'm saying is redundant with what you are saying, as I think it is, then I
> probably did a poor job of explaining myself in my last message.

When lines are broken the original Hairpin is copied to create a
Hairpin for each line.  The stencil function is applied separately to
each of these new Hairpin grobs.  It draws them with various openings
(or closings) based on the position of the spanner bounds it finds for
each: mid-line, start of line, end of line.  The spanner bound will
be, for example, a NonMusicalPaperColumn at a line break; the function
ly:item-break-dir applied to that bounding grob returns -1, 0, or
1--directions which have always left me confused.  The print function
simply looks at the bounds (and whether we have a crescendo or
decrescendo) to determine the shape, not at whether part of the
hairpin is the first piece, a middle piece, or the ending piece.

All this is super interesting, of course, but has no bearing on the
subject and I should have read what you wrote more carefully!

> English is
> not my native language and I struggle to be clear and concise with technical
> topics such as these. I apologize for the difficulties in communication that
> surely arise because of this.
>

No, your English is fine!  As I say, it's my reading comprehension
that leaves something to be desired :)

>
> I can now very comfortably get the hairpins I wanted, and I learned a lot of
> useful things in the process. I know I said it many times already but I'm
> truly grateful for your help! I never would have been able to reach a
> satisfying solution without it.
>

My pleasure!

David

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Tweaking Hairpin shape

[David Nalesnik]

Hi Stefano,

On Sat, Feb 10, 2018 at 11:14 AM, Stefano Troncaro
 wrote:
> Hi David, thank you for your suggestions, this is almost done!
>
> I decided to pass an alist to the function instead of changing the amount of
> arguments based on the procedure name, mainly because if I write more angle
> functions in the future I want to be able to do so without having to temper
> with the stencil definition. That is however a useful idea that I would have
> never thought about, and I may find it useful in the future.
>
> I have a few doubts if you don't mind.
>
> 1) At first I couldn't make the alist approach work because for some reason
> I can't define one in a let or let* block. Do you know why? I googled and I
> couldn't find an explanation.
>
> 2) Is there a way to define an alist different than a succession of acons? I
> thought I would be able to create it with a syntax like '((k1 . v1) (k2 .
> v2) ... etc) but in the end I had to settle for (acons k1 v1 (acons k2 v2
> ... (acons kn vn '(.

Not sure what you could have been doing wrong, but there are two ways you could
define the alist

(list (cons 'grob grob) (cons 'width width) (cons 'starth starth)
(cons 'endh endh))

or through quasi-quoting:

 `((grob . ,grob) (width . ,width) (starth . ,starth) (endh . ,endh))


> 3) I made the following function to make it so that the upper line of the
> hairpin runs parallel with the staff lines. It does so by finding the angle
> that is formed between the "zero-point" of the hairpin (the point where it
> begins to open) and the ending point of the higher hairpin line, that is in
> (width, height). The function takes into account that the lines of hairpins
> that go through a system break have different starting and ending heights,
> this is called "adjusted height" here.

But the spanner is cloned for each broken segment, so you aren't
actually comparing
with the initial bit.  Each new segment is simply drawn with a stencil
reflecting its
position within the whole.

With all this in mind, the function
> finds the angle of the upper line of the hairpin, and returns the negative
> of that angle, which ideally would result in that angle being 0 degrees,
> making it so that the upper line is parallel to the staff. But the end
> result is slightly off (see image). I don't know if the math is wrong or if
> this problem arises from rounding differences. If it is the later I may need
> to formulate another approach entirely. Any insight on this?

I noticed this.  I'm not great with trig, so I'm not seeing right away
how to approach this
by rotating the hairpin.  But why rotate it in the first place?  You
simply want the top or
bottom line--you also need to consider if the hairpin is above the
staff--to be horizontal.  So
create a property 'follow-staff or something and, when set, draw a
straight line for one of the two lines
which are joined to create the hairpin, instead of two lines which
split the opening width.

>
> Thank you for all the help!!

You're very welcome!

David

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Tweaking Hairpin shape

[David Nalesnik]

Hi Stefano,

On Thu, Feb 8, 2018 at 4:43 PM, Stefano Troncaro
 wrote:
> Hello again!
>
> I managed to modify David's translation of ly:hairpin::print to have it use
> two properties, Hairpin.rotate and Hairpin.straight-end, to achieve almost
> all the results I wanted.

Glad you got some use out of this!  I like the look of the
straight-edged hairpins.

>
> The idea is that Hairpin.rotate can be either a numerical value,
> representing the angle of rotation, or a procedure that returns the angle of
> rotation. In one of the examples I used the function discussed earlier in
> this thread to have it automatically detect the angle of a beam. However, I
> can't manage to make this idea work when the procedure given to
> Hairpin.rotate requires more than one variable. This is very inconvenient
> because for some cases the procedure would need to calculate again a lot of
> things that are already calculated in the process of making the stencil.

First of all, calling ly:grob-property calls any procedure the
property is set to.  The function ly:grob-property-data won't.

I don't know of any way in Scheme to overload functions or to count
arguments.  If you name your function, however, you can use
procedure-name.  (See the attached.)

HTH,
David
\version "2.19.80"

#(define (proc-number-or-false? obj)
   (or (procedure? obj)
   (number? obj)
   (eq? obj #f)))

#(define (define-grob-property symbol type? description)
   (if (not (equal? (object-property symbol 'backend-doc) #f))
   (ly:error (_ "symbol ~S redefined") symbol))

   (set-object-property! symbol 'backend-type? type?)
   (set-object-property! symbol 'backend-doc description)
   symbol)

#(map
  (lambda (x)
(apply define-grob-property x))

  `(
 (circled-tip-radius ,number? "Radius for hairpin circled tip")
 (rotate ,proc-number-or-false? "Custom rotation: a number specifies angle in degrees, a procedure will receive the grob and return an angle, #f deactivates rotation")
 (straight-end ,boolean? "Straighten the end of the hairpin when it's rotated?")
 ))


#(define broken-neighbor
   (lambda (grob)
 (let* ((pieces (ly:spanner-broken-into (ly:grob-original grob)))
(me-list (member grob pieces)))
   (if (> (length me-list) 1)
   (cadr me-list)
   '()

#(define (interval-dir-set i val dir)
   (cond ((= dir LEFT) (set-car! i val))
 ((= dir RIGHT) (set-cdr! i val))
 (else (ly:error "dir must be LEFT or RIGHT"

#(define (other-dir dir) (- dir))

#(define hairpin::print-scheme
   (lambda (grob)
 (let ((grow-dir (ly:grob-property grob 'grow-direction)))
   (if (not (ly:dir? grow-dir))
   (begin
(ly:grob-suicide! grob)
'()))

   (let* ((padding (ly:grob-property grob 'bound-padding 0.5))
  (bounds (cons (ly:spanner-bound grob LEFT)
(ly:spanner-bound grob RIGHT)))
  (broken (cons
   (not (= (ly:item-break-dir (car bounds)) CENTER))
   (not (= (ly:item-break-dir (cdr bounds)) CENTER)

 (if (cdr broken)
 (let ((next (broken-neighbor grob)))
   (if (ly:spanner? next)
   (begin
(ly:grob-property next 'after-line-breaking)
(set-cdr! broken (grob::is-live? next)))
   (set-cdr! broken #f

 (let* ((common
 (ly:grob-common-refpoint (car bounds) (cdr bounds) X))
(x-points (cons 0 0))
(circled-tip (ly:grob-property grob 'circled-tip))
(height (* (ly:grob-property grob 'height 0.2)
  (ly:staff-symbol-staff-space grob)))
(rad (ly:grob-property grob 'circled-tip-radius (* 0.525 height)))
(thick (* (ly:grob-property grob 'thickness 1.0)
 (ly:staff-symbol-line-thickness grob

   (define (inner dir)
 (let* ((b (interval-bound bounds dir))
(e (ly:generic-bound-extent b common)))
   (interval-dir-set
x-points (ly:grob-relative-coordinate b common X) dir)

   (if (interval-bound broken dir)
   (if (= dir LEFT)
   (interval-dir-set
x-points (interval-bound e (other-dir dir)) dir)
   (let* ((broken-bound-padding
   (ly:grob-property grob 'broken-bound-padding 0.0))
  (chp (ly:grob-object grob 'concurrent-hairpins)))
 (let loop ((i 0))
   (if (and (ly:grob-array? chp)
(< i (ly:grob-array-length chp)))
   (let ((span-elt (ly:grob-array-ref chp i)))
 (if (= (ly:item-break-dir (ly:spanner-bound span-elt RIGHT))
LEFT)

Re: NR 5.3.6 The \offset command: confusion in describing the examples

[David Nalesnik]

On Wed, Jun 7, 2017 at 9:00 AM, Federico Bruni  wrote:
> Il giorno mer 7 giu 2017 alle 15:57, David Nalesnik
>  ha scritto:
>>
>> Ah, OK -- that too!! (Maybe I ought to make this clearer in the
>> explanation: the default value is 2.0, so the effect of the offset command
>> would to be raise the bracket 2 + 3 = 5 staff spaces.)
>
>
> Actually, this is clear in the doc. In my mind it was +3 _from the default_
> (2).

OK, I left this alone.

See https://sourceforge.net/p/testlilyissues/issues/5141/ for my fixes.

Thanks for pointing these problems out!

David

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: NR 5.3.6 The \offset command: confusion in describing the examples

[David Nalesnik]

On Wed, Jun 7, 2017 at 8:48 AM, Federico Bruni  wrote:
>
>
> Il giorno mer 7 giu 2017 alle 15:24, David Nalesnik
>  ha scritto:
>>
>> Hi Federico,
>>
>> On Wed, Jun 7, 2017 at 8:11 AM, Federico Bruni  wrote:
>>>
>>>  Hi all
>>>
>>>  While translating, I think I caught an error in the doc:
>>>
>>>  http://lilypond.org/doc/v2.19/Documentation/notation/the-offset-command
>>>
>>>  """
>>>  The following example displaces the ‘broken’ OttavaBracket object
>>> through
>>>  its staff-padding property. Since the property takes a number, offsets
>>> is
>>>  provided with a list of numbers to account for the two segments created
>>> by
>>>  the line break. The slur piece on the first line is effectively
>>> untouched
>>>  since 0 is added to its default value. The segment on the second line is
>>>  raised two staff-spaces from its default height. The default height
>>> happens
>>>  to be 2, though it is not __necesssary__ to know this.
>>>
>>>
>
>
> another typo: "necesssary"
>

Thanks!

>
>>> {
>>>   \offset staff-padding #'(0 3) Staff.OttavaBracket
>>>   \ottava #1
>>>   c'''2 c'''
>>>   \break
>>>   c'''2 c'''
>>> }
>>>
>>>  """
>>>
>>>
>>>  - 1st problem: All the text from "The slur piece on the first line" do
>>> not
>>>  refer to the OttavBracket example, which is what is supposed to be
>>> discussed
>>>  in that paragraph, but to the example after that (the example which
>>> mimics
>>>  the effect of the \shape command).
>>
>>
>> No, the paragraph actually does refer to the OttavaBracket example.
>> The problem is a simple typo: "the slur piece" ought to read "the
>> bracket piece" or "the ottava bracket piece".  (Do you want to change
>> this, or should I?)
>>
>
> Ok, it makes sense now.
> Please take care of the change. I'm busy with updating the italian
> translation...
>

Will do.

>>>
>>>  - 2nd problem (maybe): I'm not even sure that the "slur on the second
>>> line
>>>  is raised two staff-spaces from its default height". Isn't 1.5 for the
>>>  endpoints? Here's the example:
>>>
>>>  {
>>>   c'4-\offset control-points #'(
>>>((0 . 0) (0 . 0) (0 . 0) (0 . 1))
>>>((0.5 . 1.5) (1 . 0) (0 . 0) (0 . -1.5))
>>>   ) ( f'4 g' c''
>>>   \break
>>>   d'4 c'' f' c')
>>>  }
>>>
>>
>> Again, this is remedied by fixing the typo.  The default value of
>> OttavaBracket.staff-padding is 2.0.  (An issue could be raised with my
>> referring to a setting which could be changed at some point making the
>> reference inaccurate, but that's another issue!)
>>
>>
>
> Ok, but I thought that in the OttavaBracket example the segment in the
> second line was raised by 3 (not 2) staff spaces.
>
>

Ah, OK -- that too!!  (Maybe I ought to make this clearer in the
explanation: the default value is 2.0, so the effect of the offset
command would to be raise the bracket 2 + 3 = 5 staff spaces.)

-David

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: NR 5.3.6 The \offset command: confusion in describing the examples

[David Nalesnik]

Hi Federico,

On Wed, Jun 7, 2017 at 8:11 AM, Federico Bruni  wrote:
> Hi all
>
> While translating, I think I caught an error in the doc:
>
> http://lilypond.org/doc/v2.19/Documentation/notation/the-offset-command
>
> """
> The following example displaces the ‘broken’ OttavaBracket object through
> its staff-padding property. Since the property takes a number, offsets is
> provided with a list of numbers to account for the two segments created by
> the line break. The slur piece on the first line is effectively untouched
> since 0 is added to its default value. The segment on the second line is
> raised two staff-spaces from its default height. The default height happens
> to be 2, though it is not necesssary to know this.
>
>{
>  \offset staff-padding #'(0 3) Staff.OttavaBracket
>  \ottava #1
>  c'''2 c'''
>  \break
>  c'''2 c'''
>}
>
> """
>
>
> - 1st problem: All the text from "The slur piece on the first line" do not
> refer to the OttavBracket example, which is what is supposed to be discussed
> in that paragraph, but to the example after that (the example which mimics
> the effect of the \shape command).

No, the paragraph actually does refer to the OttavaBracket example.
The problem is a simple typo: "the slur piece" ought to read "the
bracket piece" or "the ottava bracket piece".  (Do you want to change
this, or should I?)

>
> - 2nd problem (maybe): I'm not even sure that the "slur on the second line
> is raised two staff-spaces from its default height". Isn't 1.5 for the
> endpoints? Here's the example:
>
> {
>  c'4-\offset control-points #'(
>   ((0 . 0) (0 . 0) (0 . 0) (0 . 1))
>   ((0.5 . 1.5) (1 . 0) (0 . 0) (0 . -1.5))
>  ) ( f'4 g' c''
>  \break
>  d'4 c'' f' c')
> }
>

Again, this is remedied by fixing the typo.  The default value of
OttavaBracket.staff-padding is 2.0.  (An issue could be raised with my
referring to a setting which could be changed at some point making the
reference inaccurate, but that's another issue!)

Best,
David

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: TupletBracket.shorten-pair with strange output

[David Nalesnik]

On Mon, Apr 10, 2017 at 8:39 AM, Thomas Morley  wrote:
> 2017-04-10 15:28 GMT+02:00 David Nalesnik :
>> Harm,
>>
>> On Sun, Apr 9, 2017 at 5:30 PM, Thomas Morley  
>> wrote:
>>> Hi Malte,
>>>
>>> this is offtopic:
>>>
>>> 2017-04-09 22:48 GMT+02:00 Malte Meyn :
>>>>
>>>>
>>>> Am 09.04.2017 um 20:53 schrieb Thomas Morley:
>>>>> I would have expected the whole bracket to be (much) smaller, instead
>>>>> only the part of the bracket left from TupletNumber is affected.
>>>>
>>>> How do you expect any sensible output from that? 10 is so much that the
>>>> “left” end of the bracket is right from the right e
>>>
>>> Well, this happens while trying some heavy overrides, shanghaiing other 
>>> grobs.
>>> Sometimes, doing extreme things leads to detecting some weakness...
>>>
>>> I'm attempting to solve the request at
>>> http://lilypond.1069038.n5.nabble.com/Drawing-wavy-line-across-the-bars-tt201843.html
>>> in an automagical manner.
>>>
>>> Look at the attached picture.
>>> The text is the TupletNumber, the wavy line the TupletBracket. ;)
>>> Though, it gives wrong output, if the TupletBracket is not long
>>> enough. Moving the left end via shorten-pair to make room for the text
>>> gives the strange result then.
>>> Probably another property to use? It's still work in progress and it's
>>> still possible I don't get to stable state...
>>> Maybe TupletBracket is the wrong grob anyway and I should try
>>> HorizontalBracket or another Bracket. Looks I can't go for real
>>> spanners, because there ending gives a warning, when I try to let them
>>> print to the real end of a bar _and_ this bar is the last in the
>>> piece.
>>> Which may be a bug of its own:
>>>
>>> {
>>> c'1\startTextSpan
>>> \break
>>> c'1 <>\stopTextSpan
>>> }
>>>
>>> returns:
>>>
>>> atest-53.ly:1095:12: programming error: bounds of this piece aren't 
>>> breakable.
>>> c'1
>>>\startTextSpan
>>> atest-53.ly:1095:12: continuing, cross fingers
>>>
>>> The visual output is ok, though.
>>
>> TextSpanner seems like a more natural grob to co-opt!
>
> No doubt.
> Though, I found no way around the issue above. Obviouly I was too lazy
> to look into scheme-text-spanner.ly-code.
>
> Thanks a lot for it.
>
> Meanwhile I've gotten a stable code for the TupletBracket.
> I think I'll post it.
>
> And then look for the TextSpanner...
>
>
>>
>> The text spanner has its bounds set to NoteColumns. (Broken bounds
>> will be set to NonMusicalPaperColumn later.)  In your example, the
>> engraver runs out of NoteColumns and tries to set the right bound to
>> PaperColumn, which apparently doesn't work  I can put a patch for this
>> forward.
>
> That would be great!
> Ofcourse the same happens for the TrillSpanner, maybe other spanners as well.
> No clue whether this can be fixed in one go.
>

Scratch that...  There are times when the bound of a TextSpanner needs
to be set to a PaperColumn.  As for example:

{
  R1\startTextSpan
  R1\stopTextSpan
}

It's just that you will get that programming error when the
PaperColumn is at the very end of the score.  No idea how to fix that.
I do think that the error --  "bounds of this piece aren't breakable"
-- is very obscure and ought to be rewritten.  It's not "piece," as in
"this piece of music I'm typesetting."  Apparently it's saying that
one possibility of segmenting the spanner for line breaks is
impossible.  In this case, it's a little ridiculous, since we're
talking about breaking the spanner at the very end of the score..

David.

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: TupletBracket.shorten-pair with strange output

[David Nalesnik]

On Mon, Apr 10, 2017 at 8:39 AM, Thomas Morley  wrote:
> 2017-04-10 15:28 GMT+02:00 David Nalesnik :
>> Harm,
>>
>> On Sun, Apr 9, 2017 at 5:30 PM, Thomas Morley  
>> wrote:
>>> Hi Malte,
>>>
>>> this is offtopic:
>>>
>>> 2017-04-09 22:48 GMT+02:00 Malte Meyn :
>>>>
>>>>
>>>> Am 09.04.2017 um 20:53 schrieb Thomas Morley:
>>>>> I would have expected the whole bracket to be (much) smaller, instead
>>>>> only the part of the bracket left from TupletNumber is affected.
>>>>
>>>> How do you expect any sensible output from that? 10 is so much that the
>>>> “left” end of the bracket is right from the right e
>>>
>>> Well, this happens while trying some heavy overrides, shanghaiing other 
>>> grobs.
>>> Sometimes, doing extreme things leads to detecting some weakness...
>>>
>>> I'm attempting to solve the request at
>>> http://lilypond.1069038.n5.nabble.com/Drawing-wavy-line-across-the-bars-tt201843.html
>>> in an automagical manner.
>>>
>>> Look at the attached picture.
>>> The text is the TupletNumber, the wavy line the TupletBracket. ;)
>>> Though, it gives wrong output, if the TupletBracket is not long
>>> enough. Moving the left end via shorten-pair to make room for the text
>>> gives the strange result then.
>>> Probably another property to use? It's still work in progress and it's
>>> still possible I don't get to stable state...
>>> Maybe TupletBracket is the wrong grob anyway and I should try
>>> HorizontalBracket or another Bracket. Looks I can't go for real
>>> spanners, because there ending gives a warning, when I try to let them
>>> print to the real end of a bar _and_ this bar is the last in the
>>> piece.
>>> Which may be a bug of its own:
>>>
>>> {
>>> c'1\startTextSpan
>>> \break
>>> c'1 <>\stopTextSpan
>>> }
>>>
>>> returns:
>>>
>>> atest-53.ly:1095:12: programming error: bounds of this piece aren't 
>>> breakable.
>>> c'1
>>>\startTextSpan
>>> atest-53.ly:1095:12: continuing, cross fingers
>>>
>>> The visual output is ok, though.
>>
>> TextSpanner seems like a more natural grob to co-opt!
>
> No doubt.
> Though, I found no way around the issue above. Obviouly I was too lazy
> to look into scheme-text-spanner.ly-code.
>
> Thanks a lot for it.
>
> Meanwhile I've gotten a stable code for the TupletBracket.
> I think I'll post it.
>
> And then look for the TextSpanner...
>
>
>>
>> The text spanner has its bounds set to NoteColumns. (Broken bounds
>> will be set to NonMusicalPaperColumn later.)  In your example, the
>> engraver runs out of NoteColumns and tries to set the right bound to
>> PaperColumn, which apparently doesn't work  I can put a patch for this
>> forward.
>
> That would be great!
> Ofcourse the same happens for the TrillSpanner, maybe other spanners as well.
> No clue whether this can be fixed in one go.

The to-barline property lets you do what you want without the code
fix, though probably that weird programming error should be fixed
anyway!

{
  \override TextSpanner.to-barline = ##t
  c1\startTextSpan
  c1
  \break
  c1 <>\stopTextSpan
}

{
  \override TrillSpanner.to-barline = ##t
  c1\startTrillSpan
  c1
  \break
  c1 <>\stopTrillSpan
}

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: TupletBracket.shorten-pair with strange output

[David Nalesnik]

Harm,

On Sun, Apr 9, 2017 at 5:30 PM, Thomas Morley  wrote:
> Hi Malte,
>
> this is offtopic:
>
> 2017-04-09 22:48 GMT+02:00 Malte Meyn :
>>
>>
>> Am 09.04.2017 um 20:53 schrieb Thomas Morley:
>>> I would have expected the whole bracket to be (much) smaller, instead
>>> only the part of the bracket left from TupletNumber is affected.
>>
>> How do you expect any sensible output from that? 10 is so much that the
>> “left” end of the bracket is right from the right e
>
> Well, this happens while trying some heavy overrides, shanghaiing other grobs.
> Sometimes, doing extreme things leads to detecting some weakness...
>
> I'm attempting to solve the request at
> http://lilypond.1069038.n5.nabble.com/Drawing-wavy-line-across-the-bars-tt201843.html
> in an automagical manner.
>
> Look at the attached picture.
> The text is the TupletNumber, the wavy line the TupletBracket. ;)
> Though, it gives wrong output, if the TupletBracket is not long
> enough. Moving the left end via shorten-pair to make room for the text
> gives the strange result then.
> Probably another property to use? It's still work in progress and it's
> still possible I don't get to stable state...
> Maybe TupletBracket is the wrong grob anyway and I should try
> HorizontalBracket or another Bracket. Looks I can't go for real
> spanners, because there ending gives a warning, when I try to let them
> print to the real end of a bar _and_ this bar is the last in the
> piece.
> Which may be a bug of its own:
>
> {
> c'1\startTextSpan
> \break
> c'1 <>\stopTextSpan
> }
>
> returns:
>
> atest-53.ly:1095:12: programming error: bounds of this piece aren't breakable.
> c'1
>\startTextSpan
> atest-53.ly:1095:12: continuing, cross fingers
>
> The visual output is ok, though.

TextSpanner seems like a more natural grob to co-opt!

The text spanner has its bounds set to NoteColumns. (Broken bounds
will be set to NonMusicalPaperColumn later.)  In your example, the
engraver runs out of NoteColumns and tries to set the right bound to
PaperColumn, which apparently doesn't work  I can put a patch for this
forward.

I thought it might be helpful to put the changes into
input/regression/scheme-text-spanner.ly so you might try it with your
stencil.  I removed all of the grob creation stuff so this works with
ordinary TextSpanner.  Strangely, it wouldn't work with the code
that's in the current regtest, but I just happened to have a rewrite
around that mimics the C++ original more closely :)  Turns out that
works.

Best,
David.
\version "2.19.59"

#(define (add-bound-item spanner item)
   (if (null? (ly:spanner-bound spanner LEFT))
   (ly:spanner-set-bound! spanner LEFT item)
   (ly:spanner-set-bound! spanner RIGHT item)))

#(define (axis-offset-symbol axis)
   (if (eq? axis X) 'X-offset 'Y-offset))

#(define (set-axis! grob axis)
   (if (not (number? (ly:grob-property grob 'side-axis)))
   (begin
(set! (ly:grob-property grob 'side-axis) axis)
(ly:grob-chain-callback
 grob
 (if (eq? axis X)
 ly:side-position-interface::x-aligned-side
 side-position-interface::y-aligned-side)
 (axis-offset-symbol axis)

schemeTextSpannerEngraver =
#(lambda (context)
   (let ((span '())
 (finished '())
 (current-event '())
 (event-start '())
 (event-stop '()))
 (make-engraver
  (listeners
   ((text-span-event engraver event)
(if (= START (ly:event-property event 'span-direction))
(set! event-start event)
(set! event-stop event
  (acknowledgers
   ((note-column-interface engraver grob source-engraver)
(if (ly:spanner? span)
(begin
 (ly:pointer-group-interface::add-grob span 'note-columns grob)
 (if (null? (ly:spanner-bound span LEFT))
 (add-bound-item span grob)))
(if (ly:spanner? finished)
(begin
 (ly:pointer-group-interface::add-grob finished 'note-columns grob)
 (if (null? (ly:spanner-bound finished RIGHT))
 (add-bound-item finished grob)))
  ((process-music trans)
   (if (ly:stream-event? event-stop)
   (if (null? span)
   (ly:warning "You're trying to end a scheme text spanner
but you haven't started one.")
   (begin
(set! finished span)
(ly:engraver-announce-end-grob trans finished '())
(set! span '())
(set! current-event '()
   (if (ly:stream-event? event-start)
   (if (ly:stream-event? current-event)
   (ly:warning "Already have a scheme text spanner")
   (begin
(set! current-event event-start)
(set! span (ly:engraver-make-grob trans 'TextSpanner event-start))
(let ((dir (ly:event-property current-event 'direction)))
  (if (ly:dir? dir)
 

Re: TupletBracket.shorten-pair with strange output

[David Nalesnik]

Harm,

On Sun, Apr 9, 2017 at 1:53 PM, Thomas Morley  wrote:
> The following gives strange output, see attached.
>
> \version "2.19.58"
>
> {
> \override TupletBracket.shorten-pair = #'(10 . 0)
> \tuplet 1/1 {
> c'1 c'1
> }
> }
>
> I would have expected the whole bracket to be (much) smaller, instead
> only the part of the bracket left from TupletNumber is affected.
>

This behavior is ugly but expected.  You're requesting that the left
end of the bracket be moved 10 staff-spaces to the right and the right
end be moved 0 ss.

The way to shorten the bracket would be something like:

 \override TupletBracket.shorten-pair = #'(2 . 2)

Maybe there should be a cap on the amount that a bracket can be
shortened to prevent the inversion in your example?  The bracket
either won't shorten any more or that part of it disappears?

HTH,
David

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Broken slurs won't overlap end-of-measure clef change

[David Nalesnik]

On Tue, Oct 18, 2016 at 4:56 PM, Javier Ruiz-Alma  wrote:
> The first segment of a slur that spans to the next system is typeset short if 
> a clef change is present at the end of the originating measure.  The first 
> segment won't overlap the space above the changed clef.
>
> Javier Ruiz-Alma
>
> \version "2.18.2"
> \score {
>   <<
>{ c''2 c''4\( c''  \break
>  c''1\)
>  c''4 c'' c'' c''(  \break
>  c''1)
>}
>{ c''1 \clef bass
>  c'  c' \clef treble
>  c'
>}
>   >>
>   \layout { ragged-right = ##t indent = 0 }
> }
>

The problem you're seeing is that the right-bound of the slur is set
to the *left* extent of the NonMusicalPaperColumn that encompasses the
end materials of the line: Ordinarily, this means that a slur will end
slightly before a barline, which looks fine.  Unfortunately, the
cautionary clef belongs to the NonMusicalPaperColumn at the end of the
line, hence the distortion you're seeing.

(The endpoint seems to be created in
Slur_score_state::get_base_attachments in lily/slur-scoring.cc.)

What's needed is the ability to align the endpoint of a slur to
specific elements within the 'elements array of the paper column
bound.  Something like the 'break-alignable-interface which allows
flexible alignments to grobs like BarNumber.

David

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: alterBroken and ties

[David Nalesnik]

Hi Simon,

On Thu, Oct 6, 2016 at 4:58 PM, Simon Albrecht  wrote:
> On 06.10.2016 23:46, Simon Albrecht wrote:
>>
>> Hello,
>>
>> in the following snippet
>>
>> %%%
>> \version "2.19.47"
>> {
>>   1-\alterBroken color #'(black red) ~ \break
>>   1
>> }

You can't use a literal list here (with overrides either).  Which
won't solve the problem, but see below...


>> %%%
>>
>> alterBroken has no effect; it gives a warning about ~ not being a spanner.
>> Which is wrong – isn’t it? _If_ it isn’t, we should at least add a ‘Known
>> issue’ in NR 5.5.5. Or we should anyway, even if it is a bug.
>
>

This is a problem easily solved.  When tweaking, \alterBroken
recognizes spanners by the property 'span-direction.  Unfortunately,
in the case of Ties, span direction.is not set.

Try this for a fix:

\version "2.19.46"


alterBroken =
#(define-music-function (property arg item)
  (key-list-or-symbol? list? key-list-or-music?)
  (_i "Override @var{property} for pieces of broken spanner @var{item}
with values @var{arg}.  @var{item} may either be music in the form of
a starting spanner event, or a symbol list in the form
@samp{Context.Grob} or just @samp{Grob}.  Iff @var{item} is in the
form of a spanner event, @var{property} may also have the form
@samp{Grob.property} for specifying a directed tweak.")
  (if (ly:music? item)
  (if (or (eq? (ly:music-property item 'span-direction) START)
  (music-is-of-type? item 'tie-event))
  (tweak property (value-for-spanner-piece arg) item)
  (begin
(ly:music-warning item (_ "not a spanner"))
item))
  (let* ((p (check-grob-path item (*location*)
 #:default 'Bottom
 #:min 2
 #:max 2))
 (name (and p (second p)))
 (description
  (and name (assoc-get name all-grob-descriptions
(if (and description
 (member 'spanner-interface
 (assoc-get 'interfaces
(assoc-get 'meta description
(propertyOverride (append item (if (symbol? property)
   (list property)
   property))
  (value-for-spanner-piece arg))
(begin
  (ly:input-warning (*location*) (_ "not a spanner name,
`~a'") name)
  (make-music 'Music))

{
  1-\alterBroken color #`(,green ,red) ~ \break % or #(list green red)
  1
}

%%

HTH.

David

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Make flared hairpins work with the circled-tip property

[David Nalesnik]

Hi,

On Wed, Apr 6, 2016 at 2:47 PM, Simon Albrecht 
wrote:

> Hi Trevor,
>
> that’s a known deficiency:
>
> <
> https://sourceforge.net/p/testlilyissues/issues/search/?q=flared+%26%26+niente
> >
>
> Best,
> Simon
>
>
Note that a workaround is attached to the issue.

David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: crescendo & decrescendo marks not end correctly

[David Nalesnik]

Hi,

On Wed, Dec 30, 2015 at 9:54 PM, Fan Hongtao  wrote:

> When I write note of Bach's Minuet, I find that LilyPond do not write
> crescendo & decrescendo mark the way I want.
>
> With beams 21~ 24, I write something like :
>
>   a8([\< b] cis[ d] e fis |
>   g4)\! fis-. e-.\> |
>   fis4-. a,( cis |
>   d2.)\! |\break
>
> The crescendo mark is supposed to be end at the "g4" (first pitch of line
> 2), but it ends at "fis" (last pitch of line 1).
> The decrescendo mark  is supposed to be end at the "d2". (first pitch of
> line 4), but it ends at "cis" (last pitch of line 3).
>

This is expected behavior which you can override like so

\override Hairpin.to-barline = ##f

See
http://www.lilypond.org/doc/v2.18/Documentation/notation/expressive-marks-attached-to-notes
(scroll down to "Setting hairpin behavior at barlines").

David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Vertical alignment - programming error

[David Nalesnik]

On Mon, Oct 26, 2015 at 10:23 AM, David Nalesnik 
wrote:

>
>
> A more minimal example triggers the warning with TimeSignature:
>

Two with TimeSignature, one with Clef.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Vertical alignment - programming error

[David Nalesnik]

Hi Andrew,

On Mon, Oct 26, 2015 at 3:41 AM, Andrew Bernard 
wrote:

> Using a grace note set that spans two staves, reduced from a vastly more
> complex real score to a more minimal example, if I use a hairpin between
> the sfz and the p indications, I get a programming error related to
> vertical alignment that I am unable to understand, or eliminate. Can folks
> explain this? It is unclear to me whether this is a defect, or my incorrect
> usage.
>
> Andrew
>
> — compilation log
>
> Starting lilypond 2.19.29 [exp-k-p11-simpler.ly <
> http://exp-k-p11-simpler.ly/>]...
> Processing `/home/andro/work/lilypond/proportion/exp-k-p11-simpler.ly <
> http://exp-k-p11-simpler.ly/>'
> Parsing...
> Interpreting music...
> Preprocessing graphical objects...
> programming error: My pure_y_common is a VerticalAlignment, which might
> contain several staves.
> continuing, cross fingers
> programming error: My pure_y_common is a VerticalAlignment, which might
> contain several staves.
> continuing, cross fingers
> programming error: My pure_y_common is a VerticalAlignment, which might
> contain several staves.
> continuing, cross fingers
> programming error: My pure_y_common is a VerticalAlignment, which might
> contain several staves.
> continuing, cross fingers
> programming error: My pure_y_common is a VerticalAlignment, which might
> contain several staves.
> continuing, cross fingers
> Finding the ideal number of pages...
> Fitting music on 1 page...
> Drawing systems...
> programming error: bounds of this piece aren't breakable.
> continuing, cross fingers
> Layout output to `/tmp/lilypond-40hIxW'...
> Converting to `exp-k-p11-simpler.pdf'...
> Deleting `/tmp/lilypond-40hIxW'...
> Success: compilation successfully completed
> Completed successfully in 0.7”.
>
> — compilation log
>
> — snip
> \version "2.19.29"
>
> treble = {
>  \clef treble
>  \time 1/4
>
>  c''16_\sfz
>  \grace {
>\bar ""
>ees'''8^>]_\sfz\> g''^> f' a' d''
>\change Staff = middle
>b fis_\p
>  }
>  \change Staff = top
>  \bar "!"
> }
>
> bass = {
>  \clef bass
>  \time 1/4
>  c16
> }
>
> \score {
>  \new PianoStaff
>  <<
>\new Staff = "top" \with {
>}
>{ \treble }
>\new Staff = "middle" \with {
>}
>{ \bass }
> >>
>  \layout { }
> }
>
> — snip
>

 I had this error with one of my scores, and I determined that it was
caused by the initial dynamic being on a different staff than the terminal
one.  I was able to fix this (less than optimally, but just fine visually)
by changing the attachment of the initial dynamic to another note.

Well, that's not an option with your snippet.

Have you tried attaching your dynamics in this instance to spacers on the
lower staff?

By the way, I thought I'd investigate the source of the programming error.
I thought it might be the DynamicLineSpanner in your case.  Turns out to
be...BarLine.

A more minimal example triggers the warning with TimeSignature:

treble = { c''4\< \change Staff = middle c'\f }
bass = { s2 }

Beats me.

David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Broken horizontal brackets do not avoid treble clef

[David Nalesnik]

Hi Mike,

On Tue, Sep 8, 2015 at 11:57 PM, Mike Solomon  wrote:

> \version "2.19"
>
> % broken horizontal bracket intersects with bottom of treble clef
>

This has already been reported as Issue 3759:
https://sourceforge.net/p/testlilyissues/issues/3759/

What about moving the left bound of the broken spanner till after the
prefatory material like I suggest in the discussion there?  That would fix
the clef issues.

David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Patch/issue procedures (was: Randomness in layout)

[David Nalesnik]

On Sat, Aug 22, 2015 at 6:00 PM, David Nalesnik 
wrote:

> David,
>
> On Sat, Aug 22, 2015 at 2:24 AM, David Kastrup  wrote:
>
>> David Nalesnik  writes:
>>
>> [Patch]
>>
>> Maybe put it up on Rietveld and post a pointer on bug-lilypond?  Even
>> when it does not make all that much sense to create a new Google issue
>> for it, my original suggestion to post patch series to bug-lilypond
>> while we are transitioning seems nonsensical since it's Google Code that
>> is shutting down rather than Rietveld.
>>
>>
> OK, makes perfect sense.  I'll finish up the patch, and attach it to the
> thread Harm started on the bug list.
>
> David N.
>

Uh...misfire of the brain.  That would be put something up on Rietveld and
post a link to it on the buglist thread...

DN
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Patch/issue procedures (was: Randomness in layout)

[David Nalesnik]

David,

On Sat, Aug 22, 2015 at 2:24 AM, David Kastrup  wrote:

> David Nalesnik  writes:
>
> [Patch]
>
> Maybe put it up on Rietveld and post a pointer on bug-lilypond?  Even
> when it does not make all that much sense to create a new Google issue
> for it, my original suggestion to post patch series to bug-lilypond
> while we are transitioning seems nonsensical since it's Google Code that
> is shutting down rather than Rietveld.
>
>
OK, makes perfect sense.  I'll finish up the patch, and attach it to the
thread Harm started on the bug list.

David N.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Hairpin flared + circled-tip won't work together.

[David Nalesnik]

Hi Karim,

On Wed, Aug 19, 2015 at 11:01 AM, Karim Haddad 
wrote:

> Hello list,
>
> I hope this issue is not reported. If it is sorry to post it again :
>

https://code.google.com/p/lilypond/issues/detail?id=3357


>
> in this example :
>
> \version "2.19.25"
>
> {
> \override Hairpin.stencil = #flared-hairpin
> \override Hairpin #'circled-tip = ##t
>
> c'4 \< c'2 c'4 \!
> |
> \revert Hairpin.stencil
> c'4 \< c'2 c'4 \!
> |
>
> }
>
> if flared-hairpin and circled-tip are used together, the circled-tip won't
> appear. It is also the case in the stable version 2.18
>
>
I worked on this a time.  The attached is where I left off.  Note that this
will make circled tips and it will also break Ferneyhough haipins across
lines (not covered by issue 3357).  I think I put aside working on this
because of deciding how to deal with breaks in some of the more strange
shapes possible -- though it shouldn't be too hard to filter this down to a
patch for the tracker issue and leave breaks for later.

Anyway, hope this helps!

David
\version "2.19.23"


%{
  'height of any piece of a broken hairpin is always the same.  It
  represents the rise of either wing of the hairpin.
  
  The stencil Y-extent of the hairpin =
  (-y . y)
  where y =
  
for full-size pieces:
  height + (0.5 * line-thickness)
  
for reduced-size pieces:
  (2/3 * height) + (0.5 * line-thickness)
  
  Use the stencil X-extent for X of hairpin.
  
  For Y, it seems more straightforward to use 'height instead of Y-extent,
  because then we can simply draw the wing without needing to factor in
  line-thickness:
  
  height * factor  [either 1.0 or 2/3]
  
%}

#(define-public ((elbowed-hairpin coords mirrored?) grob)
   "Create hairpin based on a list of @var{coords} in @code{(cons x y)}
form.  @code{x} is the portion of the width consumed for a given line
and @code{y} is the portion of the height.  For example,
@code{'((0.3 . 0.7) (0.8 . 0.9) (1.0 . 1.0))} means that at the point
where the hairpin has consumed 30% of its width, it must
be at 70% of its height.  Once it is to 80% width, it
must be at 90% height.  It finishes at
100% width and 100% height.  @var{mirrored?} indicates if the hairpin
is mirrored over the Y-axis or if just the upper part is drawn.
Returns a function that accepts a hairpin grob as an argument
and draws the stencil based on its coordinates.
@lilypond[verbatim,quote]
#(define simple-hairpin
  (elbowed-hairpin '((1.0 . 1.0)) #t))

\\relative c' {
  \\override Hairpin #'stencil = #simple-hairpin
  a\\p\\< a a a\\f
}
@end lilypond
Broken elbowed hairpins are possible, though more complex definitions
(exceeding two pairs for @var{coords}) are not accomodated.
"
   (define (pair-to-list pair)
 (list (car pair) (cdr pair)))
   (define (normalize-coords goods x y)
 (map
  (lambda (coord)
(cons (* x (car coord)) (* y (cdr coord
  goods))
   (define (my-c-p-s points thick decresc?)
 (make-connected-path-stencil
  points
  thick
  (if decresc? -1.0 1.0)
  1.0
  #f
  #f))
   ;; outer let to trigger suicide
   (let ((sten (ly:hairpin::print grob)))
 (if (grob::is-live? grob)
 (let* ((orig (ly:grob-original grob))
(siblings (ly:spanner-broken-into orig))
(broken? (pair? siblings))
(first? (or (not broken?)
(eq? grob (first siblings
(last? (or (not broken?)
   (eq? grob (last siblings
(middle? (not (or first? last?)))
(decresc? (eq? (ly:grob-property grob 'grow-direction) LEFT))
(cresc? (not decresc?))
(niente? (ly:grob-property grob 'circled-tip #f))
; In the case of a broken hairpin, only one piece will
; be `flared' or receive a circle
(flared? (or (and decresc? first?)
 (and cresc? last?)))
(circled? (and niente?
   (or (and decresc? last?)
   (and cresc? first?
(height (ly:grob-property grob 'height 0.2))
(height (* height (ly:staff-symbol-staff-space grob)))
; calculation of radius of circle for circled tip
; by method used in `cc/hairpin.cc'
(rad (* height 0.525))  
(xex (ly:stencil-extent sten X))
; X-extent adjusted for circle at beginning or end
; of hairpin
(xex (if circled?
 (if decresc?
 (cons (car xex) (- (cdr xex) (* rad 2)))
 (cons (+ (car xex) (* rad 2)) (cdr xex)))
 xex))
(lenx (interval-length xex))
(xtrans (+ (car xex) (if decresc? lenx 0)))
(ytrans (car (ly:stencil-extent sten Y)))
(thick (ly:grob-property 

Re: Enhancement: command line option to transpose N halftones up or down

[David Nalesnik]

Hi Michael,


>
> Am 16.03.2015 um 15:02 schrieb Michael Schuerig:
>
>  I've only been using LilyPond for a rather short time, so far mostly for
>> engraving short snippets transposed into several keys for practicing. Of
>> course, the transpose command works nicely for this.
>>
>> However, it made me think of how transposing could be even nicer and now
>> I'm
>> wishing for a command line option to the lilypond command to transpose the
>> engraved document by N halftones up or down. The particular advantage
>> would
>> be that this way the original document doesn't need to be changed in any
>> way
>> in order to transpose it.
>>
>
If you're simply dealing with numbers of semitones, how would you be able
to control whether the output begins on, say, F# versus Gb?

I can imagine something which specifies that the music begin on
such-and-such a pitch.  For that, you could define a simple music
function--which really isn't saving any effort!

%%%
\version "2.19.16"

beginOn =
#(define-music-function (layout props new mus)
   (ly:pitch? ly:music?)
   #{
 \transpose #(ly:make-pitch 0 0) #new
 #mus
   #})

music = { c' d' e' f' }

{
  \music
  \beginOn es'' \music
  \beginOn g \music
}

%%%
I'd have to investigate what would be possible from the command line.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: staffSize music function unreliable at LP v2.19.16

[David Nalesnik]

On Tue, Mar 3, 2015 at 4:35 PM, Simon Albrecht 
wrote:

>  Well, there’s reason enough to redirect this to bug-lilypond, isn’t it?
> Somehow, Mozilla Thunderbird messes up the code examples, so I can’t do so
> well. Perhaps the OP’s and Harm’s first mails in the thread, respectively,
> should suffice for illustration.
>
> ~Simon
>

You might add that it appears to be a problem related to the calculation of
Stem.default-direction which appears when staff-space is changed.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

faulty interaction of line-width and minimum-length in spanners

[David Nalesnik]

Hi,

In the following snippet, the music runs right off the page.  Clearly, the
setting of line-width is not respected.  Probably, it should be
minimum-width that is ignored or adjusted along with an error being thrown.

%%%

\paper {
  line-width = 50\mm
}

{
  \override Tie.minimum-length = #40
  c''2 ~ c'' ~ \break
  c''2 ~ c''
}

%%%

David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

allow changes of scripts by type

[David Nalesnik]

Hi,

It is a common request to be able to change the defaults of specific
scripts globally.  An example would be changing the padding and font-size
of "tenuto" throughout a file.  Currently, the user needs to tweak each
instance of the right Script, a process that is tedious and error-prone.

There is a snippet which makes such changes much more convenient:
http://lilypond.org/doc/v2.19/Documentation/snippets/tweaks-and-overrides#tweaks-and-overrides-overriding-articulations-of-destinct-type

This capability ought to be part of the codebase, either through the method
in the snippet, or through the addition of a context property--something
like "scriptExceptions" to work in conjunction with "scriptDefinitions".

I would like to open a discussion of the best approach to the problem,
through tweaks (as in the snippet), or through context properties (for
which I can provide a basic patch.)

Could the bug squad open an issue for this?

Thanks!
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Retrieving information about breaks

[David Nalesnik]

Urs,

On Fri, Jan 23, 2015 at 11:17 AM, Urs Liska  wrote:

>  Hi David,
>
> thanks, that works great.
> It did *not* write to a file, but that's not the issue here.
> The main point is that it listens to implicit break events.
>

The only time it doesn't write to a file for me is when I don't save the
file before compiling with Frescobaldi.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Retrieving information about breaks (was: Partial compilation (again))

[David Nalesnik]

Hi Urs,

On Fri, Jan 23, 2015 at 9:33 AM, Urs Liska  wrote:

> Picking up that old thread seems better than starting a new one ...
>
> By now I've reached a different state and would like to come back to this
> issue with a very concrete question:
> Is it possible to determine at which positions (in terms of barnumber and
> measure-position) the final line breaks, page breaks and page turns have
> been placed in LilyPond?
> I'm sure this information has to be present at one point, but someone (I
> think it may have been David Nalesnik) expressed the opinion that engravers
> could only access explicit \break-s.
>
> I would like to write out a log file containing all break points of a
> given LilyPond run.
>

Here's a routine which will write the line breaks to a file.  Have to look
into page breaks/turns.  (It may be that you need explicit page
breaks/turns--then it's possible to read 'page-break-permission and
'page-turn-permission.)

 \version "2.19.15"

%% breaks

#(define out (open-output-file "line-breaks.txt"))

#(define (display-breaks grob)
   (if (and (grob::has-interface grob 'paper-column-interface)
(eq? #t (ly:grob-property grob 'non-musical)))
   (if (eq? 1 (ly:item-break-dir grob))
   (let* ((location (ly:grob-property grob 'rhythmic-location))
  (m (car location)))
 (format out "Line beginning at measure ~a~%" m)))
   (ly:message "Need NonMusicalPaperColumn grob to determine line
breaks.")))

\relative c'' {
  \override Score.NonMusicalPaperColumn.after-line-breaking =
#display-breaks
  \repeat unfold 30 { c d e f }
}

Hope this helps--

David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Problem with enharmonic tie in partcombine (can let LilyPond crash)

[David Nalesnik]

Hi Urs,

On Fri, Jan 16, 2015 at 6:01 AM, Urs Liska  wrote:

> Hi,
>
> I encountered a strange crash that is related to enharmonic ties.
>
> I'm using an engraver that is passed a grob.
>
> One particular snippet of input code lets now crash LilyPond.
> I can't easily produce a compiling (i.e. crashing) example because it's
> quite intertwined with project specific libraries.
> So I can't fully rule out some dependencies with the project code but I
> still have the feeling that it's more related to a recent LilyPond patch.
>
> The relevant output from the log is
>
> scm/lily.scmBacktrace:
> In /home/uliska/git/lilypond/lilypond-builds/current/out/
> share/lilypond/current/scm/lily.scm:
> 1040: 10* [ly:parse-file "/home/uliska/git/bfsc/fried/
> das-trunkne-lied/score/fullscore.ly"]
> In /home/uliska/git/lilypond/lilypond-builds/current/out/
> share/lilypond/current/ly/init.ly:
>   56: 11* (let* ((book-handler #)) (cond (# #) (# #)))
>   59: 12  (cond (# #) (# #))
> In /home/uliska/git/lilypond/lilypond-builds/current/out/
> share/lilypond/current/scm/lily-library.scm:
> ...
>  259: 13  [ly:book-process # #< Output_def> #< Output_def>
> "fullscore"]
> In unknown file:
>?: 14* [# #]
> In /home/uliska/git/bfsc/fried/das-trunkne-lied/library/ly/
> functions/annotate.ily:
>  247: 15* (begin (for-each # #) (for-each # annotations) (if
> log-annotations #))
>  250: 16* [for-each # ((# # # ...) (# # # ...) (# # #
> ...) ...)]
> In unknown file:
>?: 17* [# (# (12 . 8) # ...)]
> In /home/uliska/git/bfsc/fried/das-trunkne-lied/library/ly/
> functions/annotate.ily:
>  252: 18* (let* (#) (set! annotation #) (set! annotation #) ...)
>  258: 19* (set! annotation (assoc-set! annotation "rhythmic-location" ...))
>  258: 20* [assoc-set! (# # # # ...) "rhythmic-location" ...
>  258: 21* [location #]
>   98: 22  (let* ((col #)) (ly:grob-property col (quote rhythmic-location)))
>   98: 23* [get-paper-column #]
>   90: 24  (if (grob::has-interface grob (quote paper-column-interface))
> grob ...)
> In unknown file:
> ...
>?: 25  [get-paper-column {()}]
> In /home/uliska/git/bfsc/fried/das-trunkne-lied/library/ly/
> functions/annotate.ily:
>   90: 26  (if (grob::has-interface grob (quote paper-column-interface))
> grob ...)
>   90: 27* [grob::has-interface {()} paper-column-interface]
> In /home/uliska/git/lilypond/lilypond-builds/current/out/
> share/lilypond/current/scm/output-lib.scm:
>   24: 28  [memq paper-column-interface ...
>   24: 29* [ly:grob-interfaces {()}]
>
> /home/uliska/git/lilypond/lilypond-builds/current/out/
> share/lilypond/current/scm/output-lib.scm:24:15: In procedure
> ly:grob-interfaces in expression (ly:grob-interfaces grob):
> /home/uliska/git/lilypond/lilypond-builds/current/out/
> share/lilypond/current/scm/output-lib.scm:24:15: Wrong type argument in
> position 1 (expecting Grob): ()
>
> If I see correctly at one point the # gets lost along the way.
>

No, it's not the Tie that gets lost, it's the PaperColumn which you use to
determine the Tie's rhythmic location.  Specifically, get-paper-column
below doesn't find a column.  Now, this is sloppy on the part of the person
who supplied the code...*ahem*...me.  There ought to be some sort of check.

#(define (get-paper-column grob) (if (grob::has-interface grob
'paper-column-interface) grob (get-paper-column ;; Can't use 'X' for axis
because 'X' is also a music variable (ly:grob-parent grob 0 #(define
(location grob) (let ((col (get-paper-column grob)))
(ly:grob-property col 'rhythmic-location)))

>
> I determined the offending input to be an instance of
>
> fis ~ ges
>
> with the Tie being passed to the engraver.
> Irritatingly the crash only happens when partcombined. When compiling the
> individual part it works well.
>

The engraver you're using in conjunction with the quoted functions above is
consisted to the Score context.  If it is moved elsewhere, you won't get
columns.  Maybe there's a relationship?

Hope this is helpful--
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: LSR : Dashed slurs indicating optional slurs between lyric lines

[David Nalesnik]

Hi Pierre,

On Wed, Nov 12, 2014 at 7:57 AM, Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com> wrote:

> Hi Squad,
>
> In this snippet : http://lsr.di.unimi.it/LSR/Item?id=308
> the slur is to low.
> So I'd like to slightly change it to :
>


> [...]
> Any objection ?
>
>
Looks a lot better to me.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: lyrics extender and acciaccatura

[David Nalesnik]

On Tue, Nov 11, 2014 at 10:28 AM, David Nalesnik 
wrote:

>
>>
> Ah, OK.  That's the solution to Jean-Charles's problem.
>
>
Nevertheless, it seems that what he describes is a bug.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: lyrics extender and acciaccatura

[David Nalesnik]

On Tue, Nov 11, 2014 at 10:22 AM, David Kastrup  wrote:

>
> Not much of a surprise here.
>
> \new Staff <<
>   \new Voice = "music" { \grace c'8 }
>   \new Lyrics \with { includeGraceNotes = ##t } \lyricsto "music" { hi }
> >>
>
>
Ah, OK.  That's the solution to Jean-Charles's problem.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: lyrics extender and acciaccatura

[David Nalesnik]

On Tue, Nov 11, 2014 at 9:53 AM, David Nalesnik 
wrote:

> Hi Jean-Charles,
>
>
> The problem I see here is that the X-parent of the LyricText is being set
> to the NoteColumn of main note rather than to the grace note.  (Perhaps
> that's desirable?)
>
>
This doesn't work:

 \new Staff <<
  \new Voice = "music" { \grace c'8 }
  \new Lyrics \lyricsto "music" { hi }
>>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: lyrics extender and acciaccatura

[David Nalesnik]

Hi Jean-Charles,

On Tue, Nov 11, 2014 at 9:00 AM, Jean-Charles Malahieude 
wrote:

> Hi all,
>
> Trying to align a syllable to acciaccaturas, I came across an extender
> problem:
>
> The extender should stop *before* the rest, not when encountering the next
> acciaccatura.
>
>
The problem I see here is that the X-parent of the LyricText is being set
to the NoteColumn of main note rather than to the grace note.  (Perhaps
that's desirable?)

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Place objects by hand

[David Nalesnik]

Hi again,

On Sun, Nov 2, 2014 at 7:08 AM, David Nalesnik 
wrote:

>
> Offsetting arpeggio.positions is nice, I think.  (Though not precise;
> there is quantization which unavoidably kicks in, I think.  It's still nice
> for arpeggios across tiny intervals, where you don't want to figure out
> staff positions yourself.)
>

Sorry, I should say that such arpeggios are always drawn too short, hence
the need to override (or offset) the endpoints.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Place objects by hand

[David Nalesnik]

On Sun, Nov 2, 2014 at 6:55 AM, Trevor Daniels 
wrote:

>
> David, you wrote Sunday, November 02, 2014 12:44 PM
>
> > No, it's not a problem with \offset.
> >
> > Substitute this for the call to \offset, and you'll see that it's
> actually an issue with X-offset here:
> >
> >  \once \override DynamicText.X-offset = #-3
>
> Ah, sorry to cast invalid aspersions on \offset, David.  Still looks like
> a bug though.


Yes, I would say it's definitely a bug.  This is a bit of misuse of
self-alignment-X, but the same happens with this line:

 \once \override DynamicText.self-alignment-X = #5

So, possibly it's a problem with the Dynamics context?

Another example bites the dust.
>
>
Yeah, sorry.  It's not hard to come up with vivid demonstrations; the
difficult part of course is to find the real-world example where just that
command is what you need!

(It can be used to create the same effects as \shape, but then...there's
\shape for that.)

Offsetting arpeggio.positions is nice, I think.  (Though not precise; there
is quantization which unavoidably kicks in, I think.  It's still nice for
arpeggios across tiny intervals, where you don't want to figure out staff
positions yourself.)

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Place objects by hand

[David Nalesnik]

Hi,

On Sun, Nov 2, 2014 at 6:23 AM, Trevor Daniels 
wrote:

>
> Noeck wrote Sunday, November 02, 2014 12:46 AM
>
>
> > That would be nice, but your example puts the f on the left of the upper
> > note and not centralized between the staves (I am using 2.19.15).
>
> You're right, Joram, \offset is not a solution.  In fact, it seems to
> point to
> another problem with \offset.  In this example it prevents the dynamic
> text being centered between the staves.  I don't understand why it should
> have this effect.
>
> \version "2.18.2"
>
> \new PianoStaff <<
>   \new Staff { g-_ g c' }
>   \new Dynamics {
> \once \offset X-offset -3 DynamicText
> s\f s s\p
>   }
>   \new Staff { \clef bass g'-_ g' g' }
> >>
>
> Trevor
>

No, it's not a problem with \offset.

Substitute this for the call to \offset, and you'll see that it's actually
an issue with X-offset here:

 \once \override DynamicText.X-offset = #-3

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bug in \offset with Fingering.font-size?

[David Nalesnik]

On Sat, Nov 1, 2014 at 6:53 PM, David Nalesnik 
wrote:

>
>
> Actually, it might not be hard to enhance \offset to deal with Script.
> The defaults aren't stored in define-grobs, rather they're in script.scm.
> I'll look into that.
>

The defaults are available, yes, but then we run into the same
problem--Script.padding will not work with callbacks:

{
  \override Script.padding = #(lambda (grob) 7)
  d\staccato
}

;(
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bug in \offset with Fingering.font-size?

[David Nalesnik]

On Sat, Nov 1, 2014 at 6:21 PM, Trevor Daniels 
wrote:

>
> David Nalesnik wrote Saturday, November 01, 2014 10:53 PM
>
> >To work, \offset needs access to a default value--a number,
> > number-pair, or list of number-pairs--or a default procedure to calculate
> > these values with.  If you don't find an entry in define-grobs.scm, it
> will
> > have nothing to work with.
> >
> > DynamicLineSpanner.padding works because it's set by default to 0.6.
>
> Hm.  I wonder if it would go badly wrong if it simply assumed 0 in
> such cases? Or #'(0 . 0) - whatever it was expecting.  You'd have to assume
> the form given in the passed offset value was correct, I suppose.  In
> other words, work as if it were \override or \tweak.
>
>
That's a really interesting idea.  I'll have to try it out to see what kind
of effect it has in practice.

Wouldn't it just be duplicating the effect of an ordinary override of the
property?  Would this be a better behavior than what happens
currently--maybe give a warning "no default found, using 0.0" and at least
do something nice?

Actually, it might not be hard to enhance \offset to deal with Script.  The
defaults aren't stored in define-grobs, rather they're in script.scm. I'll
look into that.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bug in \offset with Fingering.font-size?

[David Nalesnik]

On Sat, Nov 1, 2014 at 5:29 PM, Trevor Daniels 
wrote:

>
> > David Nalesnik wrote Saturday, November 01, 2014 9:46 PM
> >>
> >> On Sat, Nov 1, 2014 at 4:34 PM, Trevor Daniels 
> wrote:
> >>>
> >>> Should \offset work with the font-size of fingering?  It doesn't seem
> to.
> >>> The default value is -5, so offsetting by -2 should give -7, with a
> size as
> >>> shown by the \override and \tweak, but both forms of \offset give 0.
> >>
> >> You're seeing this behavior with \offset because 'font-size can't be
> set to a
> >> callback, which \offset does.
> >>
> >> Enhancing 'font-size to process callbacks would be a useful feature, I
> think.
> >
> > Thanks, I see.  I agree, although a warning might be a pro tem stand-in.
> >
> > There goes my first example of its use for the docs :(
>
> It also fails to work on Script.padding, although it's fine for
> DynamicLineSpanner.padding.
> {
> c'4\fermata
> \override Script.padding = 3
> c'4\fermata
> \offset padding 3 Script
> c'4\fermata
> }
>
> Is this a similar problem?
>

Actually, no.  To work, \offset needs access to a default value--a number,
number-pair, or list of number-pairs--or a default procedure to calculate
these values with.  If you don't find an entry in define-grobs.scm, it will
have nothing to work with.

DynamicLineSpanner.padding works because it's set by default to 0.6.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bug in \offset with Fingering.font-size?

[David Nalesnik]

On Sat, Nov 1, 2014 at 4:56 PM, Trevor Daniels 
wrote:

>
> David Nalesnik wrote Saturday, November 01, 2014 9:46 PM
> >
> > On Sat, Nov 1, 2014 at 4:34 PM, Trevor Daniels 
> wrote:
> >>
> >> Should \offset work with the font-size of fingering?  It doesn't seem
> to.
> >> The default value is -5, so offsetting by -2 should give -7, with a
> size as
> >> shown by the \override and \tweak, but both forms of \offset give 0.
> >
> > You're seeing this behavior with \offset because 'font-size can't be set
> to a
> > callback, which \offset does.
> >
> > Enhancing 'font-size to process callbacks would be a useful feature, I
> think.
>
> Thanks, I see.  I agree, although a warning might be a pro tem stand-in.
>

Yes, that would be good.  I believe this question has cropped up before.


>
> There goes my first example of its use for the docs :(
>
>
Oh!  You're tackling the documentation?  I'm so glad to hear that :) :)

I might have an example or two from when I was trying (unsuccessfully of
course) to write something up.  I think I may have been fooling with
Beam.positions.

Have you seen the regtest offsets.ly?  Maybe one of those examples is
workable.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Bug in \offset with Fingering.font-size?

[David Nalesnik]

On Sat, Nov 1, 2014 at 4:34 PM, Trevor Daniels 
wrote:

> Should \offset work with the font-size of fingering?  It doesn't seem to.
> The default value is -5, so offsetting by -2 should give -7, with a size as
> shown by the \override and \tweak, but both forms of \offset give 0.
>
> {
>   \set fingeringOrientations = #'(left)
>   4
>   \override Fingering.font-size = #-7
>   
>   \once \offset font-size #-2 Fingering
>   
>   
>   
> }
>
>
You're seeing this behavior with \offset because 'font-size can't be set to
a callback, which \offset does. You can see the same behavior here:

 {
  \set fingeringOrientations = #'(left)
  4
  \override Fingering.font-size = #(lambda (grob) -7)
  
}

You get the same result setting font-size to ##f or 0.

Enhancing 'font-size to process callbacks would be a useful feature, I
think.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: empty markup causes text overlapping in lilypond >2.17

[David Nalesnik]

Eugene,

On Tue, Oct 21, 2014 at 12:12 PM, Eugene Cormier 
wrote:

> David Kastrup  gnu.org> writes:
> > Without anything suitable for reproducing the problem, this is sort of
> > anecdotal knowledge which severely reduces the chances of somebody
> > actually working on it.
>
> 'suitable' is subjective and vague. I've never done this before, and I am
> trying to help.
>

Yes, thank you very much.  Reporting bugs like this is a great service to
the project.

>
> Is this better?
>
>
> \header { title = TITLE subtitle = SUBTITLE }
> \markup { }
> \score { \repeat unfold 200 c'1 }
>
>
Yes, this is something we can easily work with.  It happened with \version
2.18 when you upgraded from 2.16?

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: empty markup causes text overlapping in lilypond >2.17

[David Nalesnik]

Hi Eugene,

You could substitute \markup \null for \markup { }

Alternatively, you could use \markup \vspace #1 (or whatever value).

I'm not sure that it is a bug--the notation says to me "make no markup,"
 whatever LilyPond did in the past.

Anyway, for the purposes of the bug list, you should formulate your
demonstration as a very short inline code snippet.

Best,
David

On Tue, Oct 21, 2014 at 7:37 AM, Eugene Cormier 
wrote:

> So for years I've been making up theory worksheets with lilypond, and in
> order to get extra vertical spacing between questions, I've used an empty
> markup block like: \markup { }
>
> since my upgrade to lilypond 2.18 I've noticed that when the empty markup
> block is added, instead of putting an empty, invisible, line of text, it
> now
> in fact freaks out and looses vertical space (like less than default, and
> overlaps with previous elements)
>
> Bug? regression? should it not work that way?
>
> here's a small example
> http://lilybin.com/0ntmpy/1
>
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Broken TextSpanner does affect horizontal spacing

[David Nalesnik]

Note that this also happens with Hairpin.

\score {
  \relative c' {
\override Hairpin.minimum-length = 50
c4\< d e f
\break
c4 d e f
\break
c4 d e f\!
  }
  \layout {
ragged-right = ##t
  }
}

Hairpin has the same sort of bounding grobs: NoteColumn for unbroken
bounds, NonMusicalPaperColumn for broken.  The middle line has
NonMusicalPaperColumn as both bounds.

On Mon, Oct 20, 2014 at 11:43 AM, David Nalesnik 
wrote:

> In the following snippet, horizontal spacing is not stretched to fit the
> broken spanner with long text on its second line.
>
> It may be that proper accommodation requires at least one bound of
> TextSpanner to be set to NoteColumn.  In the snippet, one of the bounds of
> the sibling on either the first or third line is set to NoteColumn, while
> the sibling on the middle line is bounded on left and right by
> NonMusicalPaperColumn.
>
> (The snippet outputs the bound information.)
>
> #(define (display-bounds grob)
>(format #t "spanner: ~a LEFT: ~a RIGHT: ~a~%"
>  grob
>  (ly:spanner-bound grob LEFT)
>  (ly:spanner-bound grob RIGHT)))
>
> \score {
>   \relative c' {
> \override TextSpanner.after-line-breaking = #display-bounds
> \override TextSpanner.minimum-length = #50
> \override TextSpanner.springs-and-rods = #ly:spanner::set-spacing-rods
> \override TextSpanner.bound-details.left.text =
> \markup { \upright "an excessively long text indication" }
> a4 \startTextSpan c d e
> \break
> a4 b c d
> \break
> a b c d\stopTextSpan
>   }
>   \layout {
> ragged-right = ##t
>   }
> }
>
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Broken TextSpanner does affect horizontal spacing

[David Nalesnik]

In the following snippet, horizontal spacing is not stretched to fit the
broken spanner with long text on its second line.

It may be that proper accommodation requires at least one bound of
TextSpanner to be set to NoteColumn.  In the snippet, one of the bounds of
the sibling on either the first or third line is set to NoteColumn, while
the sibling on the middle line is bounded on left and right by
NonMusicalPaperColumn.

(The snippet outputs the bound information.)

#(define (display-bounds grob)
   (format #t "spanner: ~a LEFT: ~a RIGHT: ~a~%"
 grob
 (ly:spanner-bound grob LEFT)
 (ly:spanner-bound grob RIGHT)))

\score {
  \relative c' {
\override TextSpanner.after-line-breaking = #display-bounds
\override TextSpanner.minimum-length = #50
\override TextSpanner.springs-and-rods = #ly:spanner::set-spacing-rods
\override TextSpanner.bound-details.left.text =
\markup { \upright "an excessively long text indication" }
a4 \startTextSpan c d e
\break
a4 b c d
\break
a b c d\stopTextSpan
  }
  \layout {
ragged-right = ##t
  }
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: New feature suggestion

[David Nalesnik]

On Tue, Aug 26, 2014 at 8:41 PM, Dan Eble  wrote:

> Knute Snortum  gmail.com> writes:
>
> > Just my two cent's worth:
> >
> > Adding an "n" modifier isn't saying that C Sharp is C Natural, it's an
> > assertion.  "Yes, I really mean natural.  No, I didn't just forget the
> > sharp."
>
> That sounds like a benefit, but I would think that people who value
> "cn" for that reason would prefer a language definition that did not
> include plain "c", so that Lilypond would not even produce output
> based on such an error.
>
>
The "cn" would be used presumably to reflect the fact that the output will
have a natural sign.  Requiring that C in C major be notated as "cn"--if
I'm understanding you correctly--doesn't make sense.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: New feature suggestion

[David Nalesnik]

On Tue, Aug 26, 2014 at 2:11 AM, Keith OHara  wrote:

> David Nalesnik  gmail.com> writes:
>
> > In the US, I hear people calling "c-sharp" "c" often enough.  This usage
> is
> > certainly not good practice in music theory classes (where I correct it
> > whenever I can).  I can't say anything about informal usage.
>
> The original question here was about calling, in the key of D major,
> the note c-natural by the name "c-natural".
> Here I think we would not require the student to say "c", in English.
>

Of course not.

Sorry, I think I was responding to the tendency of students to call C sharp
in the key of D major "C," which is obviously wrong!

"cn" is nice--I would say "C natural," and why not make it explicit?

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: New feature suggestion

[David Nalesnik]

On Sat, Aug 23, 2014 at 11:57 AM, David Kastrup  wrote:

> David Winfrey  writes:
>
> > Keith OHara  oco.net> writes:
> >>
> >> Phil Holmes  philholmes.net> writes:
> >> >
> >> > But if you enter b4 in F major, you'll get a natural typeset, so there
> >> can
> >> > be no confusion.  It seems like you're effectively proposing that b4
> is a
> >> b
> >> > natural I've entered accidentally, but bn4 is one I've entered
> >> deliberately.
> >> > How would Lily show the difference?
> >> >
> >>
> >> As I understand David, Lily need not show any difference.
> >> Accepting the explicit bn helps the user read his own input.
> >
> > This is what I meant; there would be no difference in the output.
> > The Lilypond parser would simply ignore 'n' if it finds 'n' when
> > it expects an accidental or note.
>
> As my musical education and practice is from a different note language,
> I cannot really say much about the motivation of that approach.  In my
> country one would never call a "cis" just "c" when talking about music,
> not even informally (but then nobody wants to get caught being informal
> anyway).  Is this really significantly different in English?
>
>
In the US, I hear people calling "c-sharp" "c" often enough.  This usage is
certainly not good practice in music theory classes (where I correct it
whenever I can).  I can't say anything about informal usage.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: self-alignment-X has negligible effects on dynamics

[David Nalesnik]

Hi Janek,


On Mon, Jul 28, 2014 at 4:12 PM, Janek Warchoł 
wrote:

> Hi,
>
> 2014-07-28 22:51 GMT+02:00 David Nalesnik :
> > What is potentially confusing (and you see how badly I've been confused)
> is
> > that the default setting of X-offset has changed.
>
> I'm not sure if i understand.  You mean that default X-offset values
> for DynamicTexts changed, or that DynamicText.X-offset uses a
> different callback now?
>

The default callback has changed.


>
> > I'm used to the old behavior
> >
> > \override DynamicText.X-offset =
> > #ly:self-alignment-interface::x-aligned-on-self
> >
> > gets it back.
>
> It doesn't, actually.  I mean,
>
> {
>   \override DynamicText.X-offset =
> #ly:self-alignment-interface::x-aligned-on-self
>   \override DynamicText.self-alignment-X = #RIGHT
>   c'4\f
>   \override DynamicText.self-alignment-X = #LEFT
>   c'4\f
>   \override DynamicText.self-alignment-X = #CENTER
>   c'4\f
> }
>
> will produce different output before and after my patch.  That's
> because before my patch DynamicTexts' position was calculated from
> x-aligned-on-self AND centered-on-x-parent, in a way that was opaque
> and not configurable by the user.  Of course, it's possible to mimic
> old behaviour.
>
>
Are you referring to that ly:make-simple-closure stuff which was commonly
found in X-offset callbacks?  If so, I don't think this was ever the
setting for DynamicText.X-offset.  At least, in 2.18.2, we have
 (X-offset . ,ly:self-alignment-interface::x-aligned-on-self)
And of course in 2.19.10, we have
(X-offset . ,ly:self-alignment-interface::aligned-on-x-parent)


 > I think that this should be made clear in the documentation, if you
> haven't
> > already done this!
>
> Yes, i should do this (or maybe some doc editor would like to help me?
> I would prefer to focus on making further changes in the code).
>
> best,
> Janek
>
> PS i may not be able to reply again until tomorrow evening (~18 UTC).
> I found that it's harder for me to focus on my day job when i read
> LilyPond email in the morning, especially in case of emotionally
> involving topics like this one.
>

I can imagine. Sorry :(

Best,
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: self-alignment-X has negligible effects on dynamics

[David Nalesnik]

On Mon, Jul 28, 2014 at 3:17 PM, Janek Warchoł 
wrote:

> Hi,
>
> 2014-07-28 16:13 GMT+02:00 David Nalesnik :
> > In the following example, the ordinary overrides of self-alignment-X
> appear
> > to have no effect on the position pf the dynamics (or an effect I can't
> > see).  Large numbers are needed for an obvious shift.
> >
> > Is this a bug, or something I'm doing wrong?
>
> You're misusing self-alignment-X.  This feature is *not* for shifting
> stuff - it is meant for aligning particular point of an object on a
> particular point of its parent.  For example, self-alignment-X = #LEFT
> means "place this object so that its left edge (i.e. left end of
> X-extent) is horizontally aligned with its parent's left edge".  It
> doesn't mean "move stuff around". Look:
>
> {
>   % draw boxes around grobs, representing their extents
>   \override DynamicText.stencil =
> #(make-stencil-boxer 0.03 0 ly:text-interface::print)
>   \override NoteHead.stencil =
> #(make-stencil-boxer 0.03 0 ly:note-head::print)
>
>   \override DynamicText.self-alignment-X = #RIGHT
>   % forte's right edge is aligned with notehead's right edge
>   c'4\f
>   \override DynamicText.self-alignment-X = #LEFT
>   % forte's left edge is aligned with notehead's left edge
>   c'4\f
>   % forte's center is aligned with notehead's center
>   \override DynamicText.self-alignment-X = #CENTER
>   c'4\f
> }
>
> % see what happens when we use wider dynamics:
> {
>   % draw boxes around grobs, representing their extents
>   \override DynamicText.stencil =
> #(make-stencil-boxer 0.03 0 ly:text-interface::print)
>   \override NoteHead.stencil =
> #(make-stencil-boxer 0.03 0 ly:note-head::print)
>
>   \override DynamicText.self-alignment-X = #RIGHT
>   % forte's right edge is aligned with notehead's right edge
>   c'2\fff
>   \override DynamicText.self-alignment-X = #LEFT
>   % forte's left edge is aligned with notehead's left edge
>   c'\fff
> }
>
> % Using numbers outside [-1, 1] interval for alignment doesn't make
> % much sense.  What does it mean if self-alignment-X = #5 ?  What is
> % aligned to what?  It's hard to say what this means in English at all.
>
> % Of course, we could use some more alignment options.
> % That's exactly what I'm doing in issue 4022.
> % With https://code.google.com/p/lilypond/issues/detail?id=4022 ,
> % this code will produce output as in the attachment:
> {
>   % draw boxes around grobs, representing their extents
>   \override DynamicText.stencil =
> #(make-stencil-boxer 0.03 0 ly:text-interface::print)
>   \override NoteHead.stencil =
> #(make-stencil-boxer 0.03 0 ly:note-head::print)
>
>   \override DynamicText.self-alignment-X = #`(,RIGHT . ,LEFT)
>   % forte's right edge is aligned with notehead's left edge
>   c'2\f
>   \override DynamicText.self-alignment-X = #`(,LEFT . ,RIGHT)
>   % forte's left edge is aligned with notehead's right edge
>   c'\f
> }
>
> % Now, if you want to "move stuff around", use X-offset, not
> % self-alignment-X:
> {
>   \override DynamicText.stencil =
> #(make-stencil-boxer 0.03 0 ly:text-interface::print)
>   \override NoteHead.stencil =
> #(make-stencil-boxer 0.03 0 ly:note-head::print)
>
>   \override DynamicText.X-offset = -2.5
>   c'2\f
>   \override DynamicText.X-offset = 1
>   c'\f
> }
>
> % Maybe some day we'll have a more unified interface for both
> % moving stuff around and aligning it - i'm working on this - but
> % for now these are separate tasks.
>
> % Is this clearer now?


This is clearer.  Thanks!

What is potentially confusing (and you see how badly I've been confused) is
that the default setting of X-offset has changed.

I'm used to the old behavior

\override DynamicText.X-offset =
#ly:self-alignment-interface::x-aligned-on-self

gets it back.

I think that this should be made clear in the documentation, if you haven't
already done this!

Sorry for any trouble,
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: self-alignment-X has negligible effects on dynamics

[David Nalesnik]

On Mon, Jul 28, 2014 at 9:25 AM, Noeck  wrote:

> Your snippet produces a different output here with 2.19.8
> (i.e. more like what I would expect)
>
>
Yup--and you get the same with 2.19.9.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

self-alignment-X has negligible effects on dynamics

[David Nalesnik]

In the following example, the ordinary overrides of self-alignment-X appear
to have no effect on the position pf the dynamics (or an effect I can't
see).  Large numbers are needed for an obvious shift.

Is this a bug, or something I'm doing wrong?

\version "2.19.10"

{
  \override DynamicText.self-alignment-X = #LEFT
  c'4\f
  \override DynamicText.self-alignment-X = #RIGHT
  c'4\f
  \override DynamicText.self-alignment-X = #CENTER
  c'4\f
  \override DynamicText.self-alignment-X = #20
  c'4\f
}

Thanks,
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

cross-staff bug?

[David Nalesnik]

Hi,

Attempting to put dynamics above cross-staff notes using the code below
leads to some awful collisions.  I've recast my example in three ways, to
no avail.

In the first example, besides the collisions, the final stem is reversed
and I get a number of programming errors:  "Grob direction requested while
calculation in progress."  (See attached for image.)

The second still has collisions and throws the programming error "My
pure_y_common is a VerticalAlignment, which might contain several staves."

The third throws no errors, but the collisions are still there.

I could of course use overrides to move objects out of the way, but I'd
much rather learn that I'm doing something wrong, recast the example, and
let LilyPond handle placement for me.

(To the suggestion that I simply put the dynamics below rather than above:
this won't always work in the piece I'm engraving.)

Thanks,
David

%%

\version "2.19.10"


 up = \change Staff = "up"

dn = \change Staff = "down"


 \new PianoStaff <<

  \new Staff = "up" {

  s8*7^\p^\< s8^\f

  }

  \new Staff = "down" {

e'8[( \up b' \dn g' \up d'' \dn b' \up f'' \dn d'' \up
a''\marcato\fermata])

  }

>>


 \new PianoStaff <<

  \new Staff = "up" {

s1

  }

  \new Staff = "down" {

e'8[(^\p^\< \up b' \dn g' \up d'' \dn b' \up f'' \dn d'' \up
a''\marcato\fermata^\f])

  }

>>


 \new PianoStaff <<

  \new Dynamics {

s8*7^\p^\< s8\f

  }

  \new Staff = "up" {

s1

  }

  \new Staff = "down" {

e'8[( \up b' \dn g' \up d'' \dn b' \up f'' \dn d'' \up
a''\marcato\fermata])

  }

>>

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidentals on repeated notes separated by rests in certain styles

[David Nalesnik]

On Tue, Jul 15, 2014 at 7:04 AM, David Nalesnik 
wrote:

>
>> Take neo-modern and neo-modern-cautionary out of the mix.  My observation
> holds for neo-modern and dodecaphonic-no-repeat, which both operate at a
> staff level.
>

*Arghh* I meant neo-modern-voice, of course.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidentals on repeated notes separated by rests in certain styles

[David Nalesnik]

On Tue, Jul 15, 2014 at 7:04 AM, David Nalesnik 
wrote:

>
>
>
> On Tue, Jul 15, 2014 at 6:52 AM, David Kastrup  wrote:
>
>>
>>
>> So what about
>>
>> { { fis'8 r8 r4 r4 r8 fis'8 } \\ { r8 cis'8 f' r2 } } ?
>>
>
> I think you mean
>
>  << { fis'8 r8 r4 r4 r8 fis'8 } \\ { r8 cis'8 f' r2 } >>
>
>
>> Should neo-modern-voice really consider the second fis'8 a repetition of
>> the first one?  I think that's stretching it.  A lot.
>>
>>
> Well, that example certainly would be.  Take neo-modern and
> neo-modern-cautionary out of the mix.  My observation holds for neo-modern
> and dodecaphonic-no-repeat, which both operate at a staff level.
>
>
In any case, the method of determining automatic accidentals should take
into account more than local alterations and the key signature.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidentals on repeated notes separated by rests in certain styles

[David Nalesnik]

On Tue, Jul 15, 2014 at 6:52 AM, David Kastrup  wrote:

>
>
> So what about
>
> { { fis'8 r8 r4 r4 r8 fis'8 } \\ { r8 cis'8 f' r2 } } ?
>

I think you mean

 << { fis'8 r8 r4 r4 r8 fis'8 } \\ { r8 cis'8 f' r2 } >>


> Should neo-modern-voice really consider the second fis'8 a repetition of
> the first one?  I think that's stretching it.  A lot.
>
>
Well, that example certainly would be.  Take neo-modern and
neo-modern-cautionary out of the mix.  My observation holds for neo-modern
and dodecaphonic-no-repeat, which both operate at a staff level.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Accidentals on repeated notes separated by rests in certain styles

[David Nalesnik]

-- Forwarded message --
From: guoguocuozuoduo 
Date: Tue, Jul 15, 2014 at 12:13 AM
Subject: RE: Accidentals on repeated notes separated by rests in certain
styles
To: David Nalesnik 


>There should be for neo-modern, neo-modern-cautionary, neo-modern-voice,
neo-modern-voice-cautionary, but not dodecaphonic-no->repeat.

For the record, I think that all of the styles should suppress the repeated
accidental, or none should.  It comes down to whether the same pitch
separated by a rest should be considered an immediate repetition.  I think
so.  Consider the following:

{ fis'4-. fis'-. }

vs.

{ fis'8 r fis' r }

It doesn't make much sense to me that there should be a difference in
behavior between the two in any style which detects immediate repetition.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: accidentals on note overlaps

[David Nalesnik]

On Mon, Jul 14, 2014 at 7:39 PM, David Nalesnik 
wrote:

> Hi,
>
> In the following example, the half-note F# counts as an immediate
> repetition and should not get an accidental in neo-modern and
> neo-modern-cautionary styles,  This issue is seen in the documentation at
> http://lilypond.org/doc/v2.19/Documentation/notation/displaying-pitches#automatic-accidentals:
> the c-sharps in the upper staff of the second measure shouldn't appear
>
>
>
...the accidental on the second C# shouldn't appear
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

accidentals on note overlaps

[David Nalesnik]

Hi,

In the following example, the half-note F# counts as an immediate
repetition and should not get an accidental in neo-modern and
neo-modern-cautionary styles,  This issue is seen in the documentation at
http://lilypond.org/doc/v2.19/Documentation/notation/displaying-pitches#automatic-accidentals:
the c-sharps in the upper staff of the second measure shouldn't appear in
these two styles.  (The repetition makes sense in neo-modern-voice and
neo-modern-voice-cautionary.)


{

  \accidentalStyle neo-modern

  << fis'1 \\ { r2 fis' } >>

}


 {

  \accidentalStyle neo-modern-cautionary

  << fis'1 \\ { r2 fis' } >>

}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Accidentals on repeated notes separated by rests in certain styles

[David Nalesnik]

Certain accidental styles suppress accidentals on immediately repeated
notes.  (These styles are neo-modern, neo-modern-cautionary,
neo-modern-voice, neo-modern-voice-cautionary, and dodecaphonic-no-repeat.)
 When a pitch repetition occurs across a rest, however, the accidental is
repeated: as an ordinary accidental or a cautionary.

Should there be an accidental on the second f-sharp in the following
example?

\new Staff {

  \accidentalStyle neo-modern

  fis'4 r fis'4 r

}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: accidentalStyle dodecaphonic-no-repeat

[David Nalesnik]

On Sat, Jul 5, 2014 at 12:24 PM, James  wrote:

>
> Thanks
>
> http://code.google.com/p/lilypond/issues/detail?id=3992
>
> James
>
>
I've figured out the problem, but I'd like to revise the
dodecaphonic-no-repeat code a little while I'm at it.  I've added some
comments and an image to the tracker to show what I propose.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: doc modification

[David Nalesnik]

Hi James,


On Thu, Jun 26, 2014 at 4:14 PM, James  wrote:

[...]


>
> What I have found is that if you use lilypond-book (which is what the
> documentation uses) I don't get the expected output but with lilypond in a
> *.ly file I do.
>
> If you are unfamiliar with how doc works in that sense, create a file
> called foo.tely and it has the content of
>
> --snip--
>
> \input texinfo @node Top
> @top
>
>
> @lilypond[ragged-right,quote]
>
> #(define (my-callback grob)
>
>   (let* (
>
>;; have we been split?
>
>(orig (ly:grob-original grob))
>
>;; if yes, get the split pieces (our siblings)
>
>(siblings (if (ly:grob? orig)
>
>  (ly:spanner-broken-into orig)
>
>  '(
>
> (if (and (>= (length siblings) 2)
>
>  (eq? (car (last-pair siblings)) grob))
>
> '(-2 . 5
>
>
> \relative c'' {
>
>   \override Tie.extra-offset = #my-callback
>
>   c1 ~ \break
>
>   c2 ~ c
>
> }
> @end lilypond
>
>
> @bye
>
> --snip--
>
> Then run
>
> lilypond-book --pdf foo.tely && texi2pdf foo.texi && evince foo.pdf
>
> I use this to check and create simple examples, snippets and the like.
>
>
I get the same result as you do when I run the above code.  However, the
moved tie also disappears when I substitute the code of the original doc
example in the template you give.

I don't know much about lilypond-book, but I assume this happens because
each line is treated individually, then linked together to form the whole.
 'extra-offset doesn't affect a system's dimensions, which is what
determines the image size.  That vertical offset moves the tie out of the
system and into oblivion.

This is pretty clear from the attached image.  I used the example in the
documentation, changing the pair to '(2 . 2.8).  The tie is cut off at the
system's extent.

I don't know enough about how the documentation examples are processed to
understand why this doesn't happen there too.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: doc modification

[David Nalesnik]

On Thu, Jun 26, 2014 at 7:49 AM, David Nalesnik
>
> Not sure why.  Attached is my result, where the tie is there  (Win7,
> 64-bit).
>
>
In any case, the altered code is equivalent to

 \alterBroken extra-offset #'((0 . 0) (-2 . 5)) Tie

so I can't understand why it wouldn't work as expected.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: doc modification

[David Nalesnik]

James,


On Thu, Jun 26, 2014 at 2:23 AM, James  wrote:

> On 26/06/14 00:33, David Nalesnik wrote:
> > On Wed, Jun 25, 2014 at 3:02 PM, Pierre Perol-Schneider <
> > pierre.schneider.pa...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> This thread :
> >>
> >>
> http://lilypond.1069038.n5.nabble.com/Positioning-spanner-at-different-height-after-line-break-td163618.html
> >>
> >> made me think that maybe it would be good to find another example for
> this
> >> part :
> >>
> >>
> http://www.lilypond.org/doc/v2.18/Documentation/extending/difficult-tweaks.html
> >>
> >> since it's now easy to tweak with the \alterBroken command.
> >>
> >>
> > Perhaps with a nested property (which \alterBroken won't handle)?
> >
> > It's worth noting that the example in the NR changes 'extra-offset
> through
> > 'after-line-breaking.  The example can be adapted to work directly as an
> > override of 'extra-offset (which is what \alterBroken does essentially):
>

[code]


> However I am not seeing the tie carried over as the original example -
> see attached
>
>
Not sure why.  Attached is my result, where the tie is there  (Win7,
64-bit).

David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: doc modification

[David Nalesnik]

On Wed, Jun 25, 2014 at 3:02 PM, Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com> wrote:

> Hi,
>
> This thread :
>
> http://lilypond.1069038.n5.nabble.com/Positioning-spanner-at-different-height-after-line-break-td163618.html
>
> made me think that maybe it would be good to find another example for this
> part :
>
> http://www.lilypond.org/doc/v2.18/Documentation/extending/difficult-tweaks.html
>
> since it's now easy to tweak with the \alterBroken command.
>
>
Perhaps with a nested property (which \alterBroken won't handle)?

It's worth noting that the example in the NR changes 'extra-offset through
'after-line-breaking.  The example can be adapted to work directly as an
override of 'extra-offset (which is what \alterBroken does essentially):

#(define (my-callback grob)

  (let* (

   ;; have we been split?

   (orig (ly:grob-original grob))

   ;; if yes, get the split pieces (our siblings)

   (siblings (if (ly:grob? orig)

 (ly:spanner-broken-into orig)

 '(

(if (and (>= (length siblings) 2)

 (eq? (car (last-pair siblings)) grob))

'(-2 . 5


\relative c'' {

  \override Tie.extra-offset = #my-callback

  c1 ~ \break

  c2 ~ c

}


--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Feature request: enable omitting the root note name when repeating chord inverted

[David Nalesnik]

Hi,


On Thu, May 1, 2014 at 4:28 AM, James  wrote:

> On 01/05/14 03:57, Henrik Pitkala wrote:
>
>> I'm not top posting
>>>
>> I'd like a feature to disable the chord root name printing, and just print
>> the slash and the inversion. The rationale for this request is a more
>> compact chord line.
>>
>> \version "2.19.6"
>> \chordmode {
>>  c c/e c/g
>> }
>>
>> Current output:
>>C  C/e  C/g
>>
>> Desired possibility:
>>C  /e  /g
>>
>> Suggestion for the command to achieve this:
>> \set chordRepeatRootNote = ##f
>>
>> There's an LSR snippet over here but it's way too tedious to use in
>> normal use:
>> http://lsr.di.unimi.it/LSR/Item?id=776
>
>
I found another workaround here:

http://www.mail-archive.com/lilypond-user%40gnu.org/msg67087.html

HTH,
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: How to catch extent of AccidentalPlacement?

[David Nalesnik]

Hi Harm,


On Fri, Apr 18, 2014 at 8:49 AM, Thomas Morley wrote:


> thanks for all your work you've put on this.
> I'm ashamed I didn't try it out so far.
> I hope I can find the time to do it the next days.
>

No problem.  If you don't get a chance to look at it, no worries!

Best,
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: How to catch extent of AccidentalPlacement?

[David Nalesnik]

Harm,


On Mon, Apr 14, 2014 at 12:07 PM, David Nalesnik
wrote:

>
>
> On Mon, Apr 14, 2014 at 8:53 AM, David Nalesnik 
> wrote:
>>
>>
>> I can't figure out where that 1.1 comes from, though.
>>
>>
> This happens in accidental-placement.cc.  It's the value of width
> calculated in position_apes.  Looks like it doesn't factor in the offsets
> to the accidentals.
>

Yes, this appears to be the culprit leading to the incorrect values from
'X-extent (and calling ly:grob-extent).

Would you mind trying out the attached patch to see if it works in whatever
context you need AccidentalPlacement info for?

With your example, I get the same values as with 2.16.2, except in the case
of the five-note chord.  The accidentals in later releases are spaced
closer, presumably as a result of skyline work.

--David
From f21d3853c6a590334848664cdcdceaf592ea9ecc Mon Sep 17 00:00:00 2001
From: David Nalesnik 
Date: Mon, 14 Apr 2014 16:54:43 -0500
Subject: [PATCH] Fixes calculation of X-extent of AccidentalPlacement.

Previously, the offsets involved in staggering of accidentals was not
included in the calculation of the width of AccidentalPlacement grobs.
---
 lily/accidental-placement.cc |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lily/accidental-placement.cc b/lily/accidental-placement.cc
index f954def..6fa61e9 100644
--- a/lily/accidental-placement.cc
+++ b/lily/accidental-placement.cc
@@ -418,7 +418,7 @@ position_apes (Grob *me,
 {
   Real mh = ape->horizontal_skylines_[d].max_height ();
   if (!isinf (mh))
-width.add_point (mh);
+width.add_point (mh + offset);
 }
 
   last_offset = offset;
-- 
1.7.0.4

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: How to catch extent of AccidentalPlacement?

[David Nalesnik]

On Mon, Apr 14, 2014 at 8:53 AM, David Nalesnik wrote:
>
>
> I can't figure out where that 1.1 comes from, though.
>
>
This happens in accidental-placement.cc.  It's the value of width
calculated in position_apes.  Looks like it doesn't factor in the offsets
to the accidentals.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: How to catch extent of AccidentalPlacement?

[David Nalesnik]

Hi Harm,


On Sat, Apr 12, 2014 at 4:53 PM, Thomas Morley wrote:

>
> One question remains: why was it changed?
> Instead of more or less simply calling the vallue via ly:grob-extent
> we now have to calculate it, looking at each Accidental separately.
> (via map and reduce)
>
> Just curious.
> I must have missed that change.
>

Well, it happened before 2.17.5 as near as I can tell.

I'll look at this some more, but the problem appears to be that there is no
'elements array for AccidentalPlacement.  You call ly:grob-extent on the
AP, which relies on the setting of 'X-extent, which is
ly:axis-group-interface::width.  This latter function ultimately uses the
contents of the elements array.  accidental-engraver.cc creates
AccidentalPlacement grobs, but not an elements array.

I can't figure out where that 1.1 comes from, though.

HTH,
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: How to catch extent of AccidentalPlacement?

[David Nalesnik]

Hi Harm,


On Sun, Mar 16, 2014 at 7:06 AM, Thomas Morley wrote:

> 2014-03-12 1:27 GMT+01:00 Thomas Morley :
> > Hi,
> >
> > for some function I need to know the extent/length of the
> AccidentalPlacement.
> >
> > With 2.16.2 I used to do something like:
> >
> > info =
> > \override Staff.AccidentalPlacement #'after-line-breaking =
> >  #(lambda (grob)
> >(display (interval-length (ly:grob-extent grob grob X)))
> >(newline))
> >
> > \relative c' {
> > \info
> > 
> > 1
> > 
> > 
> > 
> > 
> > }
> >
> > and got different values.
> >
> > With 2.18.0 and 2.19.1 it always returns the same: 1.1
> > Looks like a bug to me.
> > How to do it different?
> >
> > Cheers,
> >   Harm
>
> Noone with an idea?


Forgive the late reply...

What about something like this?

\version "2.19.3"


info =

\override Staff.AccidentalPlacement #'after-line-breaking =

#(lambda (grob)

  (let* ((accs (map cadr (ly:grob-object grob 'accidental-grobs)))

  (sys (ly:grob-system grob))

  (X-exts (map (lambda (x) (ly:grob-extent x sys X)) accs))

  (un (reduce interval-union '() X-exts)))

(display (interval-length un))

(newline)))


\relative c' {

  \info

  

  1

  

  

  

  

}


--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: example is not working

[David Nalesnik]

Oliver,


On Tue, Apr 1, 2014 at 7:36 AM, Oliver Sanftleben <
oliver.sanftle...@berlin.de> wrote:

> Hello,
>
> In LM 2.1.7 (german section: Andere rhythmische Aufteilungen), the example
> is not working.
>
> I think"\tuplet 3/2" should be replaced by"\times 2/3"
>
>
What version are you running?  It looks like you may be using documentation
for a release more current than you're using.  \tuplet is a viable command
in the current stable release.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: mark running into margin

[David Nalesnik]

Simon,


On Sun, Mar 9, 2014 at 7:45 PM, Simon Albrecht wrote:

> Hello,
>
> lenghty \marks which are at the beginning of a line tend to run into the
> margin or even out of the page. It would be nice to make the
> center-alignment more flexible and move the mark so that it stays inside
> the actual line. Minimal example attached.
> Best regards
>
>
Try inserting the following line:

\override Score.RehearsalMark.self-alignment-X = #LEFT

See
http://www.lilypond.org/doc/v2.18/Documentation/notation/aligning-objects

Hope this helps,
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: [LSR v2.18] "Complex compound time signatures" modif

[David Nalesnik]

Hi Pierre,


On Mon, Feb 24, 2014 at 6:59 AM, Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com> wrote:

> Dear Bug Squad,
>
> See the following snippet :
> http://lsr.di.unimi.it/LSR/Item?id=743
>
> Since defining compoundMeter is not needed anymore shall I erease the
> definition lines ? In comment them at the end ?
> In both cases "Complex compound time signatures" description has to be
> modified.


I see that \compoundMeter has been in the codebase since 2.13.47, so I'd
vote for removing the definition lines.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: [LSR v2.18] "Slashed beamed grace notes" enhancement proposal

[David Nalesnik]

Hi Pierre,


On Thu, Feb 20, 2014 at 6:51 AM, Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com> wrote:

> Hi Bug Squad,
>
> Enhancement for the following snippet :
> http://lsr.di.unimi.it/LSR/Item?id=721
>
> has been disscussed here:
>
> http://lilypond.1069038.n5.nabble.com/So-slashed-beamed-grace-notes-td152817.html
>
> Please find herewith the file I'd like to save for the v2.18 LSR.
> Waiting for your comments or approval
>
> Cheers,
> Pierre
>

Fine by me!  Thanks again for taking the time to do this -- it's a great
service.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \fill-line while respecting natural widths

[David Nalesnik]

Hi,


On Mon, Feb 10, 2014 at 1:26 PM, James  wrote:

> Hello,
>
> Browsing through the user threads I came across the recent thread
>
>
> http://lilypond.1069038.n5.nabble.com/fill-line-while-respecting-natural-widths-td158967.html
>
> and created
>
> http://code.google.com/p/lilypond/issues/detail?id=3860
>
> Which contains David N's workaround as I think it is useful and as the LSR
> is still back on 2.14 (I think) it would be a shame to lose this on the
> lists.
>
> Hopefully I covered everything.
>
>
@James: thanks very much for doing this!

_
@all: I've posted a comment on the issue tracker (link above), along with a
file to try out which proposes an enhancement of fill-line rather than a
new command.  I suggest that we move the discussion there.  (I notice that
no-one has starred the issue, so I thought I'd alert you here.)

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: [LSR-2.18] "Affecting items only on the left or rigth..." needs update.

[David Nalesnik]

Hi Pierre,


On Wed, Feb 12, 2014 at 12:04 PM, Pierre Perol-Schneider <
pierre.schneider.pa...@gmail.com> wrote:

> Hi All, Hi Harm,
>
> I'm stucked whith your snippet : http://lsr.dsi.unimi.it/LSR/Item?id=775
> again (equal? (ly:music-property m 'name) 'EventChord)...
>
>
I'm not sure what problem you could be having since you haven't given the
error output.

Anyway, after running convert-ly on the file, I needed to remove the "$"
from two instances of the variable 'color'.  Then the snippet works fine.

By the way, thanks for taking this project on!

HTH,
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Define custom/new \accidentalStyles (dodecaphonic minus repeated notes)

[David Nalesnik]

Hi Urs,


On Mon, Feb 3, 2014 at 3:16 AM, Urs Liska  wrote:

> Hi,
>
> searching the docs and the lilypond-user archive I couldn't find any
> relevant information.
>
> I am looking for a custom \accidentalStyle. Actually I think this is quite
> commonly used, so it would also seem like a useful addition to LilyPond
> proper.
>
> a)
> Every note gets an explicit accidental (including a natural),
> as in the 'dodecaphonic style,
> _except_ when a note is repeated immediately in the same voice.
>

I've seen it too, and I think it would be good to include it.


>
> When looking into music-functions.scm and its set-accidental-style I see
>
>  ((equal? style 'dodecaphonic)
>   (set-accidentals-properties #f
>   `(Staff ,(lambda (c p bn mp) '(#f . #t)))
>   '()
>   context))
>
>
> So it seems the way to go to make a copy of that definition (e.g. with
> comparing against 'dodecaphonic-no-repeat) and modifying the definition.
>

Yes.  That's what I do in the attached file.


>
> Unfortunately I don't have a clue how to proceed. Any trials are simply
> anwered by errors, so I'd prefer not to _try_ but to do at least _informed
> guesses_ ;-)
>
> I assume that the
> `(Staff
> expression returns the
> context pitch barnumber measureposition
> arguments for
> set-accidental-properties
> so this seems the place to define the right arguments.
>
> Unfortunately I haven't _fully_ understood lambda expressions and _barely_
> understood quoting and unquoting.
>
> So I'd be glad about hints/explanations/solutions to
>
> a)
> create a differing but valid argument list at all and
> b)
> determining which '(#f . #t) combinations to use for my purpose.
>
>

I confess that I find what goes on in the source a bit confusing, but I did
come up with something that appears to work.  I make no claims about having
done this the right way :)

First of all, I looked at clauses other than that for dodecaphonic for
inspiration, since that one is only good for hit-it-with-a-hammer
situations, and you need some refinement here. You definitely want the
initial #f which prevents old-style cancellations--the extra natural when
flat follows double-flat, but you need some variability in your setting of
the cdr--that is, auto-accidentals.

I used neo-modern as a starting point, and wrote a
'dodecaphonic-no-repeat-rule'.

I had to copy other functions from scm/music-functions.scm since they're
not define-public.

The file includes the demonstration example from the NR.

--David
\version "2.18.0"

%% LOCAL FUNCTIONS FROM scm/music-functions.scm

#(define (key-entry-notename entry)
   "Return the pitch of an @var{entry} in @code{localKeySignature}.
  The @samp{car} of the entry is either of the form @code{notename} or
of the form @code{(octave . notename)}.  The latter form is used for special
key signatures or to indicate an explicit accidental.

The @samp{cdr} of the entry is either a rational @code{alter} indicating
a key signature alteration, or of the form
@code{(alter . (barnum . measurepos))} indicating an alteration caused by
an accidental in music."
(if (pair? (car entry))
(cdar entry)
(car entry)))

#(define (key-entry-octave entry)
   "Return the octave of an entry in @code{localKeySignature}
  or @code{#f} if the entry does not have an octave.
See @code{key-entry-notename} for details."
(and (pair? (car entry)) (caar entry)))

#(define (key-entry-bar-number entry)
   "Return the bar number of an entry in @code{localKeySignature}
  or @code {#f} if the entry does not have a bar number.
See @code{key-entry-notename} for details."
(and (pair? (cdr entry)) (caddr entry)))

#(define (key-entry-measure-position entry)
   "Return the measure position of an entry in @code{localKeySignature}
  or @code {#f} if the entry does not have a measure position.
See @code{key-entry-notename} for details."
(and (pair? (cdr entry)) (cdddr entry)))

%%% END COPIED STUFF 


%% BASED on 'neo-modern-accidental-rule' %%

#(define-public (dodecaphonic-no-repeat-rule context pitch barnum measurepos)
   (let* ((keysig (ly:context-property context 'localKeySignature))
  (entry (find-pitch-entry keysig pitch #t #t)))
 (if (not entry)
  (cons #f #t)
 (let* ((entrymp (key-entry-measure-position entry))
(entrybn (key-entry-bar-number entry)))
   (cons #f
 (not 
  (and (equal? entrybn barnum) (equal? entrymp measurepos


%% FROM scm/music-functions.scm with another style added %%


#(define-public (set-accidental-style style . rest)
   "Set accidental style to @var{style}.  Optionally take a context
 argument, e.g. @code{'Staff} or @code{'Voice}.  The context defaults
to @code{Staff}, except for piano styles, which use @code{GrandStaff}
as a context."
(let ((context (if (pair? rest)
   (car rest) 'Staff))
  (pcontext (i

broken horizontal brackets don't clear prefatory material

[David Nalesnik]

In the following snippet, there is a collision between the broken analysis
bracket and the clef (see image):

\version "2.17.97"


 {

  c''1\startGroup

  \break

  c''1\stopGroup

}


 \layout {

  ragged-right = ##t

  \context {

\Voice

\consists "Horizontal_bracket_engraver"

  }

}


The collision is bad, but the problem here seems to me that the broken
analysis bracket ought to begin to the right of the prefatory material, as
other broken spanners do.  If it's felt that starting the broken bracket
more to the right is the right approach, I've got the workings of a patch
which I can post to Rietveld.


--David
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: beams look ugly when using \autochange

[David Nalesnik]

On Wed, Nov 6, 2013 at 1:32 PM, Gilberto Agostinho <
gilbertohasn...@gmail.com> wrote:

> When using \autochange, the slope of the beams look ugly against the staff
> lines:
>

It's not specifically a problem with \autochange.  You get the same
behavior with manual staff changes:

up = \change Staff = "top"
down = \change Staff = "down"

\markup { With manual staff changes }
\new PianoStaff <<
  \new Staff = "top" {
\relative c' {
\time 2/4
% can't change staff at beginning of context
% without the following:
s2*0
\down gis16 c,,32 \up e'' f \down cis, d16
\up d'16 c \down b32 bes \up d c
\bar "|."
}
  }
  \new Staff = "down" {
\clef bass
s2*0 s2
  }
>>

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: autochange sends voice to wrong clef

[David Nalesnik]

On Sat, Nov 2, 2013 at 11:36 AM,  wrote:

>
>
> % here is a case where autochange weirdly sends the top note to the
> bass clef, using lots of ledger lines
>
> version "2.16.0"
> score
> {
>  new
> PianoStaff
>  <<
>  new Staff = "up" {
>  <<
>  new Voice {
>  voiceOne
>
> autochange
>  relative c'' {
>  r2 r4 e4 % problem case: both voices go to
> base clef
>  % r2. e4 % workaround
>  }
>  }
>
>  new Voice {
>  voiceTwo
>
> autochange
>  relative c {
>  r2 r4 a4 % problem case: both voices go to
> base clef
>  % r2. a4 % workaround
>  }
>  }
>  >>
>  }
>
>  new Staff = "down" {
>
> clef bass
>  }
>  >>
> }
>
>
This won't compile as it's missing lots of backslashes and two comments
have been broken across lines.

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: [Lilypond] Incorrectly print notes with length 16*7 and 16*5

[David Nalesnik]

>Hopefully, we're good!

On Mon, Oct 28, 2013 at 11:49 AM, Trevor Daniels wrote:

> > Neither am I :)
>
> This output looks correct to me.  In the first example you're asking for a
> g16 to be displayed but for its duration to be 7/16 long followed by a
> fis16
> with duration 5/16, so filling the bar.  See
>
> http://www.lilypond.org/doc/v2.17/Documentation/notation/writing-rhythms#scaling-durations
>
> Did you intend to produce 7 g16s followed by 5 fis16s?  If so, this is the
> way to do it:
>
> \repeat unfold 7 g16
> \repeat unfold 5 fis16
>
> See
> http://www.lilypond.org/doc/v2.17/Documentation/notation/repeats
>
>
Jimmie Felidae wrote Monday, October 28, 2013 1:15 PM
>
> >> I'm not top posting.
> >
> > Tested on Lilypond 2.17.29 and latest release of 2.16.
> >
> > Example 1:
> > % Wrong output in bar 1
> > \version "2.14.0"
> >
> > \relative c {
> >  \key d \major
> >  \time 6/8
> >  g16*7 fis16*5
>
>
Or do you want the program to figure out the correct way to notate these
durations for you, using ties as needed?  This won't happen.  To tell
LilyPond to notate a G lasting 7 sixteenths (in 6/8), for example, you'd
need g4. ~ g16

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: repeated time signatures

[David Nalesnik]

Urs,


On Mon, Apr 29, 2013 at 10:32 AM, Urs Liska  wrote:

>  Hi David,
>
> Am 29.04.2013 16:15, schrieb David Nalesnik:
>
> Hi Urs,
>
>
> On Mon, Apr 29, 2013 at 9:02 AM, Urs Liska  wrote:
>
>
>
>> b) How can I achieve that the time signature is only printed if it is
>> actually different from the one currently in use?
>>
>
>  This question came up here:
>  http://www.mail-archive.com/lilypond-user@gnu.org/msg72613.html
>
>  Hopefully the engraver (see second version) still works!
>
> Yes, it works with 2.16 and 2.17.17.
>
> Thank you very much!
>

Glad to hear it!

>
>
>  c) How can I achieve the same (only displaying if really changed) for
>> key signatures and clefs?
>>
>
>  Possibly that engraver can be adapted.  (I can't try now as my job is
> calling).
>
> Although I've done my first steps with Scheme by now I don't see any
> chance to try that myself. So I'd be extremely grateful if you could give
> it a try.
>

I spent a little time with key signatures.  It quickly became apparent that
the situation is rather more complicated than with meter signatures, since
line breaking and key cancellations have to be accommodated.  I'll keep
pecking away at this.


-David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: [Spam??] repeated time signatures

[David Nalesnik]

On Mon, Apr 29, 2013 at 11:10 AM, Urs Liska wrote:

> Am 29.04.2013 17:46, schrieb Trevor Daniels:
>
>  Urs Liska wrote Monday, April 29, 2013 3:50 PM
>>
>>
>>  Am 29.04.2013 16:46, schrieb Trevor Daniels:
>>>
>>>  Urs Liska wrote  Monday, April 29, 2013 3:02 PM

  The NR (1.2.3 "Displaying Rhythms") states that time signatures "are
> printed at the beginning of a piece and whenever the time signature
> changes."
>
> But if I write
>
> music = {
> \time 3/4
> R2.*4
> \time 3/4
> R2.
> }
>
> the time signature is printed a second time although it doesn't change
> (to my understanding)
>
 Rather surprisingly there is no bug report describing this, although it
 has been present since the beaming behaviour was changed several
 years ago.

  a) Is this intended behaviour? And if yes, shouldn't it be documented
>
 I don't think it is intended, so it should be recorded as a bug.
 Copying to bug list for bug squad.

>>> I think, David Nalesnik's comment is valid.
>>> http://lists.gnu.org/archive/**html/lilypond-user/2013-04/**
>>> msg00852.html
>>>
>>> So I think the behaviour shouldn't be changed, but the documentation.
>>>
>> I read the opposite in David's comment.  The documentation correctly
>> says what should happen, and what used to happen prior to around 2010,
>> but since then the code has behaved incorrectly IMHO.  So the
>> bug report should record the incorrect behaviour of the code.  As we don't
>> usually document buggy behaviour, the docs should not be changed,
>> unless, maybe, to remove the statement either way.
>>
>> Trevor
>>
>>
> Hm, maybe I've done too much today to see it ;-)
> Rereading David's comment after yours, I don't see anymore what he
> intended to say.
>

Sorry if I was unclear!  I simply meant that if the user types in a extra
\time LilyPond should by default only print the time signature once.
That's the correct practice, after all.  If the user really wants that
extra time signature, he/she should have to specify this in some way,
perhaps by setting some property like "showAllTimeSignatures" (which would
be set by default to #f).


> But if you're right and a repeated \time signature shouldn't be displayed
> by default, would it be then the right way to include David's engraver by
> default? And do the same for key signatures and clefs?
>
> Or should a fix be tackled at a lower level?
>

The engraver could be used as a workaround, but a fix at a lower level
would definitely be better.


-David



On Mon, Apr 29, 2013 at 11:10 AM, Urs Liska wrote:

> Am 29.04.2013 17:46, schrieb Trevor Daniels:
>
>  Urs Liska wrote Monday, April 29, 2013 3:50 PM
>>
>>
>>  Am 29.04.2013 16:46, schrieb Trevor Daniels:
>>>
>>>  Urs Liska wrote  Monday, April 29, 2013 3:02 PM

  The NR (1.2.3 "Displaying Rhythms") states that time signatures "are
> printed at the beginning of a piece and whenever the time signature
> changes."
>
> But if I write
>
> music = {
> \time 3/4
> R2.*4
> \time 3/4
> R2.
> }
>
> the time signature is printed a second time although it doesn't change
> (to my understanding)
>
 Rather surprisingly there is no bug report describing this, although it
 has been present since the beaming behaviour was changed several
 years ago.

  a) Is this intended behaviour? And if yes, shouldn't it be documented
>
 I don't think it is intended, so it should be recorded as a bug.
 Copying to bug list for bug squad.

>>> I think, David Nalesnik's comment is valid.
>>> http://lists.gnu.org/archive/**html/lilypond-user/2013-04/**
>>> msg00852.html
>>>
>>> So I think the behaviour shouldn't be changed, but the documentation.
>>>
>> I read the opposite in David's comment.  The documentation correctly
>> says what should happen, and what used to happen prior to around 2010,
>> but since then the code has behaved incorrectly IMHO.  So the
>> bug report should record the incorrect behaviour of the code.  As we don't
>> usually document buggy behaviour, the docs should not be changed,
>> unless, maybe, to remove the statement either way.
>>
>> Trevor
>>
>>
> Hm, maybe I've done too much today to see it ;-)
> Rereading David's comment after yours, I don't see anymore what he
> intended to say.
>
> But if you're right and a repeated \time signature shouldn't be displayed
> by default, would it be then the right way to include David's engraver by
> default? And do the same for key signatures and clefs?
>
> Or should a fix be tackled at a lower level?
>
> Urs
>
>
>
> __**_
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/**listinfo/bug-lilypond

Re: \alterBroken doesn't work for properties accessed before line breaking

[David Nalesnik]

Mike,

On Thu, Feb 21, 2013 at 7:38 AM, David Nalesnik wrote:

>
>
>> m...@mikesolomon.org writes:
>>
>> > If \alterBroken tries to set a property consulted before line breaking,
>> it results in the property having an incorrect value:
>> >
>> > For example...
>> >
>> > \relative c'' {
>> >   \alterBroken #'direction #'(UP DOWN) Staff.DynamicLineSpanner
>> >   %\override Staff.DynamicLineSpanner.direction = #UP %% no issues
>> >   a\< \repeat unfold 38 a a\p
>> > }
>> >
>>
>>
> This doesn't fix the problem, but if you use variables like UP and DOWN or
> color names, etc., you need to quasiquote them:
>
> >   \alterBroken #'direction #`(,UP ,DOWN) Staff.DynamicLineSpanner
>
> Either that, or use the numerical equivalents:
>
> >   \alterBroken #'direction #'(1 -1) Staff.DynamicLineSpanner
>
>
By "doesn't fix the problem," I mean that you can't set the pieces of the
hairpin to different values.  Is this what you meant when you write above
about "having an incorrect value," or are you referring to the warning
which results from your code snippet (which disappears when you quasiquote
or use numbers for direction)?

Just wondering if I've solved your problem and revealed another problem in
the process!

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \alterBroken doesn't work for properties accessed before line breaking

[David Nalesnik]

On Thu, Feb 21, 2013 at 3:02 AM, Colin Hall  wrote:

>
> m...@mikesolomon.org writes:
>
> > If \alterBroken tries to set a property consulted before line breaking,
> it results in the property having an incorrect value:
> >
> > For example...
> >
> > \relative c'' {
> >   \alterBroken #'direction #'(UP DOWN) Staff.DynamicLineSpanner
> >   %\override Staff.DynamicLineSpanner.direction = #UP %% no issues
> >   a\< \repeat unfold 38 a a\p
> > }
> >
>
>
This doesn't fix the problem, but if you use variables like UP and DOWN or
color names, etc., you need to quasiquote them:

>   \alterBroken #'direction #`(,UP ,DOWN) Staff.DynamicLineSpanner

Either that, or use the numerical equivalents:

>   \alterBroken #'direction #'(1 -1) Staff.DynamicLineSpanner

--David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: problem with 'outside-staff-padding

[David Nalesnik]

On Tue, Oct 16, 2012 at 2:52 PM, Marek Klein  wrote:

> Thanks for the report, this has been added as
> http://code.google.com/p/lilypond/issues/detail?id=2910
>

Thanks, Marek!
-David

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

problem with 'outside-staff-padding

[David Nalesnik]

Hi,

In the example in the documentation of 2.17.4 relating to
'outside-staff-padding, the last line of text ought to be close to the
previous text.

Compare:
2.16 - 
http://www.lilypond.org/doc/v2.16/Documentation/notation/vertical-collision-avoidance
2.17.4 - 
http://www.lilypond.org/doc/v2.17/Documentation/notation/vertical-collision-avoidance

The problem is visible first with 2.17.1.

Thanks,
David

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

\balloonGrobText does not work properly with slurs

[David Nalesnik]

The image shows what happens when \balloonGrobText is used with a slur.
 Uncommenting the \override demonstrates a possible workaround. I tried
this code in 2.14.2 with the same result.

\version "2.15.39"

\new Voice \with { \consists "Balloon_engraver" }
\relative c'' {
  % uncommenting the following line is a possible workaround
  %\override BalloonTextItem #'X-extent = ##f
  \balloonGrobText #'Slur #'(0 . 2) \markup { "I'm a slur!" }
  c( d e f)
}

Thanks,
David
<>___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Staccato alignment on stem side

[David Nalesnik]

David,


> script-interface:
>
> This grob interface is used in the following graphical object(s): *note
> AccidentalSuggestion::, *note DynamicText:: and *note Script::.
>
> Quite a lot of stuff created without an articulation-type, so you should
> be using eqv? rather than string= ...
>
>
Ah, I get it--an error will of course be returned if I compare a string
with anything but a string...
(And of course I should revise this so that I only collect articulations...)

Thanks very much,
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Staccato alignment on stem side

[David Nalesnik]

Hi Janek,

On Tue, May 22, 2012 at 1:01 PM, Janek Warchoł wrote:

> Hi David,
>
> On Tue, May 22, 2012 at 7:51 PM, David Nalesnik
>  wrote:
> >> In procedure string= in expression (string= (ly:prob-property # #)
> >> "staccato"):
> >> Wrong type argument in position 1 (expecting string): ()
> >
> > Try changing the context from Staff to Voice  -- that's where I should
> have
> > put it in the first place!
>
> unfortunately, nothing changed.  The same error.


Hmmm...  I'm really not sure.  I tried it with a multi-voice example and no
problems there...  I guess I would really need to see an example where it's
breaking down.

But since staccato is the only articulation that has a value set for
'toward-stem-shift, you could just override it to 0 and revert it for when
you want the staccato-alone orientation.  (I must say that the engraver
seems like overkill! :)  )

-David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Staccato alignment on stem side

[David Nalesnik]

Hi Janek,


> > \layout {
> >  \context {
> >\Staff
> >\consists #stacc-corrector
> >  }
> > }
>
> i wanted to include your engraver in Fried Songs project, but there's an
> error.
> Unfortunately i don't have time to debug this problem at the moment,
> but maybe the error message will give you an idea what is happening?
>
> In procedure string= in expression (string= (ly:prob-property # #)
> "staccato"):
> Wrong type argument in position 1 (expecting string): ()
>
> I've just pasted the definition and context modification to main .ly
> file...  When i used it as a separate snippet everything was fine.
>

Try changing the context from Staff to Voice  -- that's where I should have
put it in the first place!

HTH,
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Staccato alignment on stem side

[David Nalesnik]

Hi Urs,

On Wed, May 16, 2012 at 4:02 AM, Urs Liska  wrote:

> Am 16.05.2012 10:50, schrieb Colin Hall:
>
>  Urs Liska  googlemail.com>  writes:
>>
>>> The following example shows that staccato points are aligned differently
>>> from other articulations when on the stem side.
>>>
>> Thanks, Urs. I reproduced this on 2.12.3 and 2.15.38 so I have created a
>> tracker
>> here:
>>
>> http://code.google.com/p/**lilypond/issues/detail?id=2535
>>
>> Cheers,
>> Colin.
>>
>>
>> __**_
>> bug-lilypond mailing list
>> bug-lilypond@gnu.org
>> https://lists.gnu.org/mailman/**listinfo/bug-lilypond
>>
> But then again, what _is_ intended behaviour?
> As I understand it the staccato is deliberately placed nearer to the stem.
>

Yes, in script.scm it is assigned a default of 0.5 for 'toward-stem-shift,
so it appears mid-way between the stem and center of the notehead.

What should be the solution:
> - align all articulations like the staccato if on the stem side?
> - align a staccato non-default if there are other articulations present?
>

If you like this last orientation (I do), try this as a workaround:

\version "2.15.38"

#(define stacc-corrector
  (lambda (ctx)
(let ((articulations '())
  (staccato '()))
  (make-engraver
(acknowledgers ((script-interface engraver grob source-engraver)
  (set! articulations (cons grob articulations))
  (if (string= (ly:prob-property (event-cause grob)
'articulation-type) "staccato")
  (set! staccato grob
   ((stop-translation-timestep trans)
 (if (and (ly:grob? staccato)
  (or (> (length articulations) 1)
  (boolean? (ly:prob-property (event-cause staccato)
'parenthesize
 (set! (ly:grob-property staccato 'toward-stem-shift) 0))
 (set! articulations '())
 (set! staccato '()))

\relative e'' {
 e-. -| -- e-\parenthesize -. -|--
 \voiceTwo
 e-. -| -- e-\parenthesize -. -|--
 e-\parenthesize -. e-.
 \voiceOne
 e,-- e-. e-\parenthesize -.
}

\layout {
  \context {
\Staff
\consists #stacc-corrector
  }
}

As usual, simpler suggestions welcome!

HTH,
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Feature request: Display bezier control-points

[David Nalesnik]

Hi Harm,


> how about:
>
> \version "2.14.2"
>
> #(define (make-cross-stencil coords)
>  (ly:stencil-add
>   (make-line-stencil 0.1 (- (car coords) 0.2) (- (cdr coords) 0.2)
>  (+ (car coords) 0.2) (+ (cdr coords) 0.2))
>   (make-line-stencil 0.1 (- (car coords) 0.2) (+ (cdr coords) 0.2)
>  (+ (car coords) 0.2) (- (cdr coords) 0.2
>
> #(define (display-control-points line)
>  (lambda (grob)
>   (let ((stencil (ly:slur::print grob))
> (cps (ly:grob-property grob 'control-points)))
>
>   (ly:stencil-add stencil
>  (ly:stencil-in-color
> (make-cross-stencil (second cps))
> 1 0 0)
> (ly:stencil-in-color
> (make-cross-stencil (third cps))
> 1 0 0)
> (if (eq? line #t)
> (make-line-stencil 0.05 (car (second cps)) (cdr (second cps))
> (car (third cps))  (cdr (third cps)))
> empty-stencil)
> )
> )))
>
> \relative c'' {
>  \override Slur #'stencil = #(display-control-points #t)
>  c2( d e f)
> }
>

Looks great!  Makes this even more fun to play around with :)

-David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Feature request: Display bezier control-points

[David Nalesnik]

Hi Urs,


>> But this really _is_ helping to find suitable values for the
>> control-points.
>>
>
I'm very glad to hear this!


>
>>  * Although I know bezier curves from vector graphics software, I
>>also was convinced that the 'control-points' were four points on
>>the curve that define its shape.
>>
>
Initially I did too...


>  * In fact the first and last are such points, whereas the middle two
>>'control-points' are the 'handles'.
>>-> Is this explained somewhere?
>>  * From seeing the crosses I now realize that (when using your
>>function) all four offsets are relative to LilyPond's original
>>decision.
>>Well, if you think about it, that's quite obvious, but I always
>>assumed that if I change one offset the other control-points would
>>be affected accordingly.
>>But in fact they aren't. So if I for example raise the endpoint of
>>a slur, the third control-point may well get below the slur.
>>This makes me understand the seemingly strange behaviour of the
>>slurs when fiddling with the offsets.
>
>  * -> Probably it'll greatly improve my 'tweaking experience', even
>>if I have seen this only once, not to speak if I manage to include
>>this in a real-life workflow ...
>>So, many thanks once more, David!
>>
>
You're very welcome!  I've been playing around with it a bit myself, and
I'm becoming more and more convinced that something like this would be a
very useful feature.

You can also use it to show you the effect of changing other properties.
 For example, you can see the effects of overriding 'height-limit and
'eccentricity.  I'm finding it very instructive.

At least one thing, which I did do right now:
> I compiled one score with and without your cross setting, and comparing
> the two pdfs with Alt-Tab showed that the layout was perfectly identical -
> except for the additional crosses.
> So obviously the crosses are added after LilyPond decides about the layout.
>

I'm very glad to hear this!  My worry was that the crosses might push
staves further apart in extreme situations.

Thanks for trying this out!

-David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Feature request: Display bezier control-points

[David Nalesnik]

On Thu, May 3, 2012 at 7:08 PM, David Nalesnik wrote:

> Hi Urs,
>
> > It would be a really valuable feature if one could let LilyPond display
>> > the control-points of a bezier curve.
>> > I would imagine something like a cross or a point at the middle two
>> > control-points.
>>
>
> I think this would be very helpful, so that you can visualize exactly what
> these control-points are that you're setting.  (It must be a common
> misconception that they are points on the actual curve.)
>


Of course, you can use the slur tweak tool in LilyPondTool!

-David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Feature request: Display bezier control-points

[David Nalesnik]

Hi Urs,

> It would be a really valuable feature if one could let LilyPond display
> > the control-points of a bezier curve.
> > I would imagine something like a cross or a point at the middle two
> > control-points.
>

I think this would be very helpful, so that you can visualize exactly what
these control-points are that you're setting.  (It must be a common
misconception that they are points on the actual curve.)

I'm not sure what impact this may have on the layout, but you could do
something like the following:

\version "2.15.37"

#(define (make-cross-stencil coords)
  (ly:stencil-add
(make-line-stencil 0.1 (- (car coords) 0.2) (- (cdr coords) 0.2)
   (+ (car coords) 0.2) (+ (cdr coords) 0.2))
(make-line-stencil 0.1 (- (car coords) 0.2) (+ (cdr coords) 0.2)
   (+ (car coords) 0.2) (- (cdr coords) 0.2

#(define display-control-points
  (lambda (grob)
(let ((stencil (ly:slur::print grob))
  (cps (ly:grob-property grob 'control-points)))

  (ly:stencil-add stencil
  (make-cross-stencil (second cps))
  (make-cross-stencil (third cps))

\relative c'' {
  \override Slur #'stencil = #display-control-points
  c( d e f)
}

Hope you find this helpful!

-David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: lower portion of image cut off in NR examples

[David Nalesnik]

Keith,

On Mon, Apr 16, 2012 at 12:10 AM, Keith OHara  wrote:

> David Nalesnik  gmail.com> writes:
>
> > Part of the beam and the leftmost stem is cut off in the lower staff of
> > each of the examples here:
> >
> > http://www.lilypond.org/doc/v2.15/Documentation/notation/displaying-
> pitches#automatic-accidentals
> >
>
> This was bug 1043 but after we solved the more worrisome parts, we
> considered
> it closed.
>
> I've filed a bug <http://code.google.com/p/lilypond/issues/detail?id=2482>
> with a suggestion to create a less-distracting image for the documentation.
>
>
OK, thanks!

-David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

lower portion of image cut off in NR examples

[David Nalesnik]

Hi,

Part of the beam and the leftmost stem is cut off in the lower staff of
each of the examples here:

http://www.lilypond.org/doc/v2.15/Documentation/notation/displaying-pitches#automatic-accidentals

(I notice the same problem in the 2.14.2 documentation --
http://www.lilypond.org/doc/v2.14/Documentation/notation/displaying-pitches#automatic-accidentals
)

Thanks,
David
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Center a number above a measure

[David Nalesnik]

Hi Colin,


> Thanks very much for that, David. I've updated the issue tracker with
> your post and your engraver.
>
> http://code.google.com/p/lilypond/issues/detail?id=2445
>
>
>
Thank you!
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: Center a number above a measure

[David Nalesnik]

Hi,

2012/3/28 Colin Hall 

>
> On Wed, Mar 28, 2012 at 05:02:49PM +0100, James wrote:
> > hello,
> >
> > 2012/3/28 Clément Ryder :
> > ...etc.
> >
> > So it seems that this is really the enhancement request stated before
> >
> > http://code.google.com/p/lilypond/issues/detail?id=146 (if not
> > exactly, in essence).
>
> Both enhancement requests are on the same general topic, which is
> automated counting of items (e.g. bars) in the music that are repeated.
>
> This recent request from Clement, as Xavier pointed out, calls for
> slightly more advanced features than the one which resulted in issue
> 146.
>
> > I just don't see any value in poo-pooing useful suggestions, (complex
> > or otherwise), for a problem that we already know about and is not
> > implemented 'elegantly' in the code.
> >
> > Eventually you just end up irritating people and they stop helping.
>
> Understood, but I'm ok with the comments. Xavier's suggestion of using
> that context property was a good one.
>
> In summary then:
>
> Lilypond does not have a feature for automated counting of arbitrary
> items. See issue trackers 2445 and 146 for more information.
>
> Code has been contributed for making a start on implementing this
> feature. See the issue trackers above.
>
> You can get a "1" above a single bar of full measure rest using this
> syntax:
> {
>  \set restNumberThreshold = #0
>  R1 | R1 | R1 |
> }
>
> Lilypond does not support counting the first item of a percent repeat.
>
> I hope Clement will prepare a simple documentation suggestion to make the
> role
> of restNumberThreshold clearer.
>
> Cheers,
> Colin.
>
> --
>
> Colin Hall
>
> ___
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>

I've come up with the following Scheme engraver which allows you to create
a counter above measures (whether they are associated with repeated music
or not). This should work in 2.14.2, too, provided that you adjust the
position of \measureCounterStart and \measureCounterEnd.

Basically, it creates spanners attached on both sides to a
NonMusicalPaperColumn. (Originally, I used BarLines--not sure which is the
better approach.) For the spanner, I've defined a new grob, MeasureCounter.

It would be nice to be able to control what prefatory items to consider
when centering (for example, between bars alone, between time signature and
clef change, etc.), but I have no idea how to proceed with this. (I believe
Harm's functions allow you this control. How to do this with an engraver?)

I acknowledge NoteColumns so that the number will move out of the way of
notes, but I can't figure out how to (gracefully) include only those
columns within a given measure--I'm getting the first note-column of the
next measure into my 'elements array. This, of course, messes with vertical
and horizontal positioning. Any thoughts?

Another problem is that the spacing between systems isn't adjusted.

Anyway, I hope that I'm on the right track with this, and I'd welcome any
feedback!

Thanks,
David

P.S.  I realize that the function define-event-class is problematic at the
moment . . .


measureCounterEngraver.ly
Description: Binary data
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond