On 8/10/09 1:54 AM, "Marc Hohl" <address@hidden> wrote:
Carl Sorensen schrieb:
[...]
The *specific* behavior you have requested can be achieved by the following:
#(define myBool #f)
myMusicFunc =
#(define-music-function (parser location) ()
#{
\once \override Slur #'dummyProperty = ##t
#})
#(define-public (slur::boolean grob)
;; just a test function to try and switch boolean values
(let ((my-prop (ly:grob-property grob 'dummyProperty #f)))
(display "\nWithin callback\n")
(display "my-prop: ")(display my-prop)(newline)
(if my-prop
(display "Actions for #t go here...")
(display "Actions for #f go here..."))
(set! myBool #f)
(display "myBool: ")(display myBool)(newline)
(ly:slur::print grob)))
\layout {
\context {
\Voice
\override Slur #'stencil = #slur::boolean
}
}
\relative c'' {
c4 ( c )
\myMusicFunc
c ( c )
c ( c )
\myMusicFunc
c ( c )
}
Ok, I played with your code - the result on console for my-prop is #f #t
#t #f,
but it should be #f #t #f #t, isn't it?
Hmm, you're right.
I did a little bit of extra investigating, including adding the following to
slur::boolean
(display "cause: ")(display (event-cause grob))(newline)
When I did this, I found that the first #f came from the first line of
music, the first #t came from the second line of music, the second #t came
from the *last* line of music, and the second #f came from the third line of
music. Somehow the connected slurs changed the order of evaluation, but the
slurs that I expected to have the property #t did in fact have the property
#t.