lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GSoC] spanners project update


From: Jan-Peter Voigt
Subject: Re: [GSoC] spanners project update
Date: Fri, 1 Jul 2016 09:28:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

Am 01.07.2016 um 09:21 schrieb Urs Liska:


Am 01.07.2016 um 09:01 schrieb Nathan Chou:
Thanks David and Urs for replying.

There is a detail I would like to clarify. David suggested allowing \=
to optionally specify the parent context in which a cross-voice
spanner's information is shared (although I am not sure how that would
be done with a key-list, since I think the spanner id itself is a
string).
Right.  Maybe it should rather be a key?  That would also make
comparison generally faster than string comparisons.
Would I convert a string input to a key, or should I only accept a key
as a valid id? The latter seems more convenient but I imagine would
break backward compatibility.

Backward compatibility is not always a requirement. If a convert-ly rule
can be written for the change then it isn't an issue at all.


If this context is not specified, should it default to Score or Staff
(or something else)?
Nothing at all?  Namely don't look anywhere else unless asked for?
So cross voice spanners should only work if the context to share
information is specified, right? If the context is not specified and
there is no default, the spanner id would only be used within the same
voice and not made known to any other contexts.

Hm. If this is a limitation required by the implementation then it's
acceptable. But from a user perspective I would be very surprised if an
ID isn't recognized without an explicitly named context around it. Isn't
that the (one) idea of an ID in general, defining an ID and have it
addressable from anywhere?
Well, the spanner-id is used right now to have multiple slurs (or other spanners) in the same Voice. So keeping the spanner-ids in the current Voice would only preserve the current behaviour, if no other context is given. But OTOH (IISC) it wouldn't break the current implementation, as long, as IDs are Score-unique and not only Voice-unique. My preference would be to place it in the Score-context.

Jan-Peter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]