"Erik Appeldoorn" <ursus.k...@ziggo.nl> writes: > Thanks Nick, > > Interesting to see how your solution differs from the one Kieren and Carl > offered. More than one way to reach the goal. Nice.
Disagree. Seems rather like more than one trick to reach the goal. >From a user interface perspective, I find both solutions distastefully tricky. Now there is something to be said against tieing into a different voice like that musically: it messes up the audible voice situation. Unless dictated by the instrument (and then there is little necessity to write the tie explicitly), it is cleaner to articulate the note separately. When playing accordion and doing something like <e g>8( <c e>) I have to take pains to explicitly break off the e from the first note a slight bit earlier so that the voice/note relation does not get messed up. The notation manual says something like _Using ties with arpeggios_ Ties are sometimes used to write out arpeggios. In this case, two tied notes need not be consecutive. This can be achieved by setting the `tieWaitForNote' property to `#t'. The same feature is also useful, for example, to tie a tremolo to a chord, but in principle, it can also be used for ordinary consecutive notes. \relative c' { \set tieWaitForNote = ##t \grace { c16[ ~ e ~ g] ~ } <c, e g>2 \repeat tremolo 8 { c32 ~ c' ~ } <c c,>1 e8 ~ c ~ a ~ f ~ <e' c a f>2 \tieUp c8 ~ a \tieDown \tieDotted g8 ~ c g2 } Personally, I think that "tieWaitForNote" should be the default behavior. There is nothing whatsoever gained that I can see by dropping explicit ties. Or even tieWaitForNoteOrEndRepeatOrEndAlternative. And a wrong tie is more noticeable if it produces output. It is a reasonable help to emit a warning for possibly unintended non-matching ties, but probably it might be nice if adding another tie will silence the warning, like g8 ~~ c g2. That feels nicer than a global override like tieWaitForNote, even if you may use \once \override instead. Feature request for tracker? -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user