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))
   

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 <f...@inventati.org> wrote:
> Il giorno mer 7 giu 2017 alle 15:57, David Nalesnik
> <david.nales...@gmail.com> 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: TupletBracket.shorten-pair with strange output

[David Nalesnik]

On Mon, Apr 10, 2017 at 8:39 AM, Thomas Morley <thomasmorle...@gmail.com> wrote:
> 2017-04-10 15:28 GMT+02:00 David Nalesnik <david.nales...@gmail.com>:
>> Harm,
>>
>> On Sun, Apr 9, 2017 at 5:30 PM, Thomas Morley <thomasmorle...@gmail.com> 
>> wrote:
>>> Hi Malte,
>>>
>>> this is offtopic:
>>>
>>> 2017-04-09 22:48 GMT+02:00 Malte Meyn <lilyp...@maltemeyn.de>:
>>>>
>>>>
>>>> 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 <thomasmorle...@gmail.com> wrote:
> 2017-04-10 15:28 GMT+02:00 David Nalesnik <david.nales...@gmail.com>:
>> Harm,
>>
>> On Sun, Apr 9, 2017 at 5:30 PM, Thomas Morley <thomasmorle...@gmail.com> 
>> wrote:
>>> Hi Malte,
>>>
>>> this is offtopic:
>>>
>>> 2017-04-09 22:48 GMT+02:00 Malte Meyn <lilyp...@maltemeyn.de>:
>>>>
>>>>
>>>> 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 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: 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]

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: Vertical alignment - programming error

[David Nalesnik]

On Mon, Oct 26, 2015 at 10:23 AM, David Nalesnik <david.nales...@gmail.com>
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: 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]

David,

On Sat, Aug 22, 2015 at 2:24 AM, David Kastrup d...@gnu.org wrote:

 David Nalesnik david.nales...@gmail.com 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: Patch/issue procedures (was: Randomness in layout)

[David Nalesnik]

On Sat, Aug 22, 2015 at 6:00 PM, David Nalesnik david.nales...@gmail.com
wrote:

 David,

 On Sat, Aug 22, 2015 at 2:24 AM, David Kastrup d...@gnu.org wrote:

 David Nalesnik david.nales...@gmail.com 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: Hairpin flared + circled-tip won't work together.

[David Nalesnik]

Hi Karim,

On Wed, Aug 19, 2015 at 11:01 AM, Karim Haddad karim.had...@ircam.fr
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 grob 

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 simon.albre...@mail.de
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 u...@openlilylib.org 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 u...@openlilylib.org 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 u...@openlilylib.org 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 #Book # Output_def # Output_def
 fullscore]
 In unknown file:
?: 14* [#procedure #f (trans) #Translator Scheme_engraver ]
 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 #procedure #f (g) ((# # # ...) (# # # ...) (# # #
 ...) ...)]
 In unknown file:
?: 17* [#procedure #f (g) (#Grob Tie  (12 . 8) #Mom 3/2 ...)]
 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 #Grob Tie ]
   98: 22  (let* ((col #)) (ly:grob-property col (quote rhythmic-location)))
   98: 23* [get-paper-column #Grob Tie ]
   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 #Grob Tie  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]

Hi Jean-Charles,

On Tue, Nov 11, 2014 at 9:00 AM, Jean-Charles Malahieude lily...@orange.fr
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: lyrics extender and acciaccatura

[David Nalesnik]

On Tue, Nov 11, 2014 at 9:53 AM, David Nalesnik david.nales...@gmail.com
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]

On Tue, Nov 11, 2014 at 10:22 AM, David Kastrup d...@gnu.org 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 10:28 AM, David Nalesnik david.nales...@gmail.com
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: Place objects by hand

[David Nalesnik]

Hi,

On Sun, Nov 2, 2014 at 6:23 AM, Trevor Daniels t.dani...@treda.co.uk
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: Place objects by hand

[David Nalesnik]

On Sun, Nov 2, 2014 at 6:55 AM, Trevor Daniels t.dani...@treda.co.uk
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 again,

On Sun, Nov 2, 2014 at 7:08 AM, David Nalesnik david.nales...@gmail.com
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: Bug in \offset with Fingering.font-size?

[David Nalesnik]

On Sat, Nov 1, 2014 at 4:34 PM, Trevor Daniels t.dani...@treda.co.uk
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)
   a'-24
   \override Fingering.font-size = #-7
   a'-2
   \once \offset font-size #-2 Fingering
   a'-2
   a'-\tweak font-size #-7 -2
   a'-\offset font-size #-2 -2
 }


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)
  a'-24
  \override Fingering.font-size = #(lambda (grob) -7)
  a'-2
}

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: Bug in \offset with Fingering.font-size?

[David Nalesnik]

On Sat, Nov 1, 2014 at 4:56 PM, Trevor Daniels t.dani...@treda.co.uk
wrote:


 David Nalesnik wrote Saturday, November 01, 2014 9:46 PM
 
  On Sat, Nov 1, 2014 at 4:34 PM, Trevor Daniels t.dani...@treda.co.uk
 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 5:29 PM, Trevor Daniels t.dani...@treda.co.uk
wrote:


  David Nalesnik wrote Saturday, November 01, 2014 9:46 PM
 
  On Sat, Nov 1, 2014 at 4:34 PM, Trevor Daniels t.dani...@treda.co.uk
 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 6:21 PM, Trevor Daniels t.dani...@treda.co.uk
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 6:53 PM, David Nalesnik david.nales...@gmail.com
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: 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 eugenecorm...@gmail.com
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: empty markup causes text overlapping in lilypond 2.17

[David Nalesnik]

Eugene,

On Tue, Oct 21, 2014 at 12:12 PM, Eugene Cormier eugenecorm...@gmail.com
wrote:

 David Kastrup dak at 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

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: 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 david.nales...@gmail.com
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

Re: New feature suggestion

[David Nalesnik]

On Tue, Aug 26, 2014 at 2:11 AM, Keith OHara k-ohara5...@oco.net wrote:

 David Nalesnik david.nalesnik at 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 Tue, Aug 26, 2014 at 8:41 PM, Dan Eble d...@faithful.be wrote:

 Knute Snortum ksnortum at 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 Sat, Aug 23, 2014 at 11:57 AM, David Kastrup d...@gnu.org wrote:

 David Winfrey d...@patriot.net writes:

  Keith OHara k-ohara5a5a at oco.net writes:
 
  Phil Holmes mail at 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

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

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

[David Nalesnik]

On Mon, Jul 28, 2014 at 9:25 AM, Noeck noeck.marb...@gmx.de 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

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

[David Nalesnik]

On Mon, Jul 28, 2014 at 3:17 PM, Janek Warchoł janek.lilyp...@gmail.com
wrote:

 Hi,

 2014-07-28 16:13 GMT+02:00 David Nalesnik david.nales...@gmail.com:
  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]

Hi Janek,


On Mon, Jul 28, 2014 at 4:12 PM, Janek Warchoł janek.lilyp...@gmail.com
wrote:

 Hi,

 2014-07-28 22:51 GMT+02:00 David Nalesnik david.nales...@gmail.com:
  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

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]

-- Forwarded message --
From: guoguocuozuoduo brian777...@hotmail.com
Date: Tue, Jul 15, 2014 at 12:13 AM
Subject: RE: Accidentals on repeated notes separated by rests in certain
styles
To: David Nalesnik david.nales...@gmail.com


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 repeated notes separated by rests in certain styles

[David Nalesnik]

On Tue, Jul 15, 2014 at 6:52 AM, David Kastrup d...@gnu.org 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]

On Tue, Jul 15, 2014 at 7:04 AM, David Nalesnik david.nales...@gmail.com
wrote:




 On Tue, Jul 15, 2014 at 6:52 AM, David Kastrup d...@gnu.org 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

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

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

Re: accidentals on note overlaps

[David Nalesnik]

On Mon, Jul 14, 2014 at 7:39 PM, David Nalesnik david.nales...@gmail.com
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

Re: accidentalStyle dodecaphonic-no-repeat

[David Nalesnik]

On Sat, Jul 5, 2014 at 12:24 PM, James pkx1...@gmail.com 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 pkx1...@gmail.com 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]

James,


On Thu, Jun 26, 2014 at 2:23 AM, James pkx1...@gmail.com 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 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]

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: How to catch extent of AccidentalPlacement?

[David Nalesnik]

Hi Harm,


On Fri, Apr 18, 2014 at 8:49 AM, Thomas Morley thomasmorle...@gmail.comwrote:


 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]

Hi Harm,


On Sat, Apr 12, 2014 at 4:53 PM, Thomas Morley thomasmorle...@gmail.comwrote:


 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]

On Mon, Apr 14, 2014 at 8:53 AM, David Nalesnik david.nales...@gmail.comwrote:


 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]

Harm,


On Mon, Apr 14, 2014 at 12:07 PM, David Nalesnik
david.nales...@gmail.comwrote:



 On Mon, Apr 14, 2014 at 8:53 AM, David Nalesnik 
 david.nales...@gmail.comwrote:


 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 david.nales...@gmail.com
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]

Hi Harm,


On Sun, Mar 16, 2014 at 7:06 AM, Thomas Morley thomasmorle...@gmail.comwrote:

 2014-03-12 1:27 GMT+01:00 Thomas Morley thomasmorle...@gmail.com:
  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
  c d
  cis d1
  cis dis
  cis dis eis
  cis dis eis fis
  cis dis eis fis gis
  }
 
  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

  c d

  cis d1

  cis dis

  cis dis eis

  cis dis eis fis

  cis dis eis fis gis

}


--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 simon.albre...@mail.dewrote:

 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 pkx1...@gmail.com 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 u...@openlilylib.org 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 (if (pair? rest)
(car 

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
attachment: horizontal-bracket-bug.png___
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, sniv...@catesby.org 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 t.dani...@treda.co.ukwrote:

  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 u...@openlilylib.org 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 u...@openlilylib.org 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 lilyli...@googlemail.comwrote:

 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.htmlhttp://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 lilyli...@googlemail.comwrote:

 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.htmlhttp://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-lilypondhttps://lists.gnu.org/mailman/listinfo/bug-lilypond

___
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 colingh...@gmail.com 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: \alterBroken doesn't work for properties accessed before line breaking

[David Nalesnik]

Mike,

On Thu, Feb 21, 2013 at 7:38 AM, David Nalesnik david.nales...@gmail.comwrote:



 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

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
attachment: balloon-text-bug.png___
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 Janek,

On Tue, May 22, 2012 at 1:01 PM, Janek Warchoł janek.lilyp...@gmail.comwrote:

 Hi David,

 On Tue, May 22, 2012 at 7:51 PM, David Nalesnik
 david.nales...@gmail.com 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]

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 Urs,

On Wed, May 16, 2012 at 4:02 AM, Urs Liska lilyli...@googlemail.com wrote:

 Am 16.05.2012 10:50, schrieb Colin Hall:

  Urs Liskalilyliskaat  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=2535http://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-lilypondhttps://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 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: Feature request: Display bezier control-points

[David Nalesnik]

On Thu, May 3, 2012 at 7:08 PM, David Nalesnik david.nales...@gmail.comwrote:

 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,


 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]

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: lower portion of image cut off in NR examples

[David Nalesnik]

Keith,

On Mon, Apr 16, 2012 at 12:10 AM, Keith OHara k-ohara5...@oco.net wrote:

 David Nalesnik david.nalesnik at 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 colingh...@gmail.com


 On Wed, Mar 28, 2012 at 05:02:49PM +0100, James wrote:
  hello,
 
  2012/3/28 Clément Ryder themu...@gmail.com:
  ...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

Re: Center a number above a measure

[David Nalesnik]

Hi,

2012/3/28 Colin Hall colingh...@gmail.com


 On Wed, Mar 28, 2012 at 05:02:49PM +0100, James wrote:
  hello,
 
  2012/3/28 Clément Ryder themu...@gmail.com:
  ...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

Re: tuplet number on cross-staff kneed-beam

[David Nalesnik]

Hi, again --

 I've also attached a pared-down version of the file which should work
 in either release, as is.  It distills the problem a little more -- at
 the expense of centering the number directly on the beam . . .


My last email included an image produced with 2.12.3.  Attached is the
output from 2.14.1.

Best,
David
attachment: tuplet-number-function-minimal.png___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: tuplet number on cross-staff kneed-beam

[David Nalesnik]

Hi, Colin --

On 7/5/11, Colin Campbell c...@shaw.ca wrote:

 This will probably require an issue, David, but could you send the code
 you used to produce the 2.12.3 version, please?  I can't reproduce the
 previous stable example, in order to confirm the regression, because
 your Scheme-ing gives an error:
 LilyPond 2.12.3 [music.ly] starting (preview mode)...
 Processing `music.ly'
 Parsing...
 Interpreting music...
 Preprocessing graphical objects...
 Finding the ideal number of pages...
 Fitting music on 1 page...
 Drawing systems...music.ly:19:12: In procedure + in expression (+
 (ly:grob-property beam #) (/ # 2)):
 music.ly:19:12: Wrong type argument in position 1: ()
 LilyPond [music.ly] exited with return code 1.

Oops -- yes, the error happened because 'thickness is now
'beam-thickness.  I've attached the file I used for the 2.12.3 image.

I've also attached a pared-down version of the file which should work
in either release, as is.  It distills the problem a little more -- at
the expense of centering the number directly on the beam . . .

I hope that in some way this is useful :)

Thank you for your help!

-David
\version 2.12.3

#(define (tuplet-number-to-beam tuplet-number)
  (let* ((tuplet-bracket (ly:grob-object tuplet-number 'bracket))
 (note-column (ly:grob-parent tuplet-number X))
 (stem (ly:grob-object note-column 'stem))
 (beam (ly:grob-object stem 'beam)))

 ;; Move (invisible) TupletBracket to beam, taking number with it
 (ly:grob-set-property! tuplet-bracket 'positions (ly:grob-property beam 'positions))

 ;; Number is now centered on beam.  Offset it based on width of beam and height
 ;; of tuplet number.
 (ly:grob-set-property! tuplet-number 'Y-offset
 (-
   (+
 (ly:grob-property beam 'thickness)
 (/ (interval-length (ly:grob::stencil-height tuplet-number)) 2))



\new PianoStaff 
  \new Staff = 1 {
s4
  }
  \new Staff = 2 {
\relative c {
  \clef bass
  \override TupletNumber #'after-line-breaking = #tuplet-number-to-beam
  \times 2/3 {
c8
\change Staff = 1
c''
\change Staff = 2
c,,
  }
}
  }



\version 2.12.3

#(define (tuplet-number-to-beam tuplet-number)
  (let* ((tuplet-bracket (ly:grob-object tuplet-number 'bracket))
 (note-column (ly:grob-parent tuplet-number X))
 (stem (ly:grob-object note-column 'stem))
 (beam (ly:grob-object stem 'beam)))

 ;; Move (invisible) TupletBracket to beam, taking number with it
 (ly:grob-set-property! tuplet-bracket 'positions (ly:grob-property beam 'positions


\new PianoStaff 
  \new Staff = 1 {
s4
  }
  \new Staff = 2 {
\relative c {
  \clef bass
  \override TupletNumber #'after-line-breaking = #tuplet-number-to-beam
  \times 2/3 {
c8
\change Staff = 1
c''
\change Staff = 2
c,,
  }
}
  }





tuplet-number-function-minimal.pdf
Description: Adobe PDF document
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond