bug-lilypond
[Top][All Lists]
Advanced

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

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


From: David Nalesnik
Subject: Re: Problem with enharmonic tie in partcombine (can let LilyPond crash)
Date: Fri, 16 Jan 2015 07:53:16 -0600

Hi Urs,

On Fri, Jan 16, 2015 at 6:01 AM, Urs Liska <address@hidden> 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


reply via email to

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