Am 30.03.2015 um 00:20 schrieb Simon Albrecht:
Am 29.03.2015 um 23:46 schrieb Kevin Barry:
For sure the voice context limitations are a pain, and if I knew how, I
would write a function for starting and finishing slurs without the need
for creating a hidden voice, but I don't even know if it is possible.
In my
own head, I imagine that LilyPond `thinks' in voices and there isn't
much
that can be done about that.
I think the idea is something similar in some way to \change Staff,
which shows that there is a possibility to switch contexts. The
difference is that \change Staff moves an entire (voice) context to
the other staff, whereas a slur is only one object in the bottom
context. Only brainstorming: what about creating an ephemeral
below-bottom ‘spanner’ context, which only lives as long as the slur
(or other spanner? probably only for tie, slur, phrasing slur) is
there, and supports writing \change Voice = "foo"? Or one might be
reminded of a Lyrics context being associated with a Voice context –
in a similar way might a ‘Spanner’ context be associated to a Voice
context, and thus the slur get linked to the notes?
Unfortunately, I can’t say anything about implementation, though I
like the idea … ;-)
Yours, Simon
As far as I can understand this goes very much along the line I would
think it should be approached. And I can't imagine that there are
fundamental obstacles against it. Although of course I can't think about
an implementation either.
Urs
Practically 100% of my work is either piano
music or music reduced to two staves, so I bump up against this issue
all
the time. I never use the part combiner.
I obviously don't know how necessary this limitation is, but iirc the
old
DOS program SCORE required that the whole score be reentered for the
purposes of adding slurs.
How hard would it be to write a cross-voice slur function?
On Sun, Mar 29, 2015 at 6:49 PM, Urs Liska <u...@openlilylib.org> wrote:
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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel