Am 13.07.2013 18:15, schrieb Trevor Daniels:
Urs Liska wrote Saturday, July 13, 2013 4:59 PM
The same goes for ties spanning clef or staff changes. I suggest catching such
cases and implicitly pass on to a slur.
That might look acceptable in the printed score, but it would break the midi
output.
Trevor
OK, maybe I have to think more precisely.
We can't replace a tie for a slur on the input level (i.e. pretend the
user had entered a slur).
Besides the midi output issue this would also interfere with another
slur that is already in effect. A setting like
c d( e~ e f)
should of course not be affected when the tie is replaced for a slur.
I don't know enough about how LilyPond works internally, but isn't the
midi generation somewhat independent from the graphical output?
In other words: Is the engraver that prints a tie in any way related at
all with the midi output?
If not it should be possible to defer the graphical generation of the
the grob from the Tie to the Slur engraver in such cases, isn't it?
The following cases should be caught:
c~ \clef alto c
c~ \change Staff = "down" c
c~ bis
BTW when checking them I noticed that the second line crashes lilypond
when "preprocessing graphical objects".
Urs
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user