Hi,
this has been discussed numerous times, but I think I'll have to bring
it up once more: the limitations that slurs, dynamics and other spanners
can't cross voice borders. This limitation is a major inconvenience for
users: New users are regularly confused, using hidden voices to work
around the limitation is actually an ugly workaround, and it's not
acceptable to be forced to use such workarounds for reasonably common
things. And now I've come to suffer from an issue where this limitation
is a real PITA: the partcombiner.
I find it quite obscure to tame the partcombiner to do its work anyway
(for example, when you're facing an issue you don't have a real way to
tell what "mode" it currently is in because the last switch could have
happened about anywhere, and in any of the voices taking part in the
combination). But I've come to the conclusion that very often the
partcombiner has to make ugly choices because it's bound to keep voice
contexts alive during the whole spanners. Often it remains in
partcombineApart mode for ridiculously long ranges, just because a slur
has to be closed in the same voice as it has begun. And this kind of
issue is usually sooo awkward to solve because you might end up
inserting a hidden voice to achieve the slurring but have to restrict
that to the partcombined staff while not using it for individual part
printing etc.
So I want to bring that up once more: Why do we still have this
limitation? Is it an inherent problem that can't be fixed, is it just
because noone cared (or had the chance) to fix it, or is it "only"
because we didn't explicitly think about the right way to deal with it
semantically and with regard to syntax?
I mean, I can't imagine it makes a serious difference when it comes to
*engrave* a slur. It may make a difference for managing and maintaining
contexts, but just as it is possible to add a hidden voice to accomplish
a cross-voice item it should be possible to create a built-in solution
for that.
This wouldn't fix the partcombiner limitations, but it would at least
make it possible to think about improvements.
Any ideas?
Urs, frustrated ...
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
