From 73aa07d06cefeed6c521d78feb6ce3b904a97081 Mon Sep 17 00:00:00 2001 From: David Kastrup Date: Wed, 15 Feb 2012 06:43:18 +0100 Subject: [PATCH] changes.itely: Mention event-chord-wrap! and \eventChords. --- Documentation/changes.tely | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/Documentation/changes.tely b/Documentation/changes.tely index b35850445f..058a0d5c0e 100644 --- a/Documentation/changes.tely +++ b/Documentation/changes.tely @@ -114,11 +114,16 @@ representation: Rhythmic events like @code{LyricEvent} and @code{NoteEvent} are no longer wrapped in @code{EventChord} unless they have been actually entered as part of a chord in the input. If you manipulate music expressions in Scheme, the new behavior may require -changes in your code. The advantages of making input and music match -more closely are numerous: music functions previously worked differently -when used inside or outside of chords. Now they are the same, including -all the possibilities of argument parsing. You can now use music -variables inside of chords: a construct like +changes in your code. Calling the music function @code{\eventChords} or +the Scheme function @code{event-chord-wrap!} converts to the old +representation; using one of those might be easiest for keeping legacy +code operative. + +The advantages of making input and music match more closely are +numerous: music functions previously worked differently when used inside +or outside of chords. Now they are the same, including all the +possibilities of argument parsing. You can now use music variables +inside of chords: a construct like @lilypond[verbatim,quote,ragged-right] tonic=fis' { <\tonic \transpose c g \tonic> } -- 2.39.2