Hello Harm and David, Thanks for the explanations and example!
I copied a sample from the snippets and modified it, without taking care about detailed semantics. Now I know how to do things the right way depending on the context. JM > Le 25 juin 2017 à 10:44, David Kastrup <[email protected]> a écrit : > > Thomas Morley <[email protected] <mailto:[email protected]>> > writes: > >> 2017-06-25 8:40 GMT+02:00 Menu Jacques <[email protected]>: >>> Thanks Simon for the idea. >>> >>> I’ve defined the following Scheme function for my needs, with accidental >>> style forced to ‘forget' for the given note: >>> >>> editorialAccidental = >>> #(define-music-function >>> (note) >>> (ly:music?) >>> #{ >>> \once\accidentalStyle forget >>> \once\set suggestAccidentals = ##t >>> #note >>> #}) >>> >>> { >>> \editorialAccidental cis4 >>> cis4 >>> dis4 >>> \editorialAccidental cis4 >>> } >>> >>> JM >> >> >> Hi Jaques, >> >> while calling a variable, here 'note', in embedded lily-code, i.e. in >> #{ ... #}, always use $note not #note. >> Doing something with #note destructively changes 'note', so you can't >> access the unchanged 'note' anymore. >> Working on $note works on a copy of 'note' so you still have access to >> the original 'note'. > > In this particular use case of using the material (of kind ly:music?) > exactly once, #note is actually correct. This possibility of using > material uncopied and destructively is useful for processing large > amounts of music like with > > \relative c' { 100 lines of stuff } > > In cases like that, not creating a copy for music that is just > transitionally used is fine. In many other cases, you are right that it > isn't, and the error symptoms are hard to understand and occur only > under some circumstances (uses of \relative and \transpose are often > involved but by no means the only triggers). > > -- > David Kastrup
_______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
