[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