On 2013/01/12 12:54:25, Ian Hulin (gmail) wrote:
This LGTM, but with one really big question: do we really still need
\tupletSpan
at all?
It is for setting a default. If you have a back-and-forth between
tuplets and full notes (which is essentially the case for which there
has been substantial clamor for \triplet as a "shorthand" for \tuplet
3/2), then it might save typing. I am not sure that the saved typing is
worth having a non-local side-effect in the form of a context property,
but \triplet did not strike me as all that necessary either.
The start point for this work was to make "easy triplets and tuplets",
i.e. make
handling of all the triplets and *uplets less daunting and a bit more
readable
by humans.
Here is the NR example for tupletSpannerDuration and \times:
>
> {
> \set tupletSpannerDuration = #(ly:make-moment 1 4)
> \times 2/3 { c8 c c c c c }
> }
>
Ugly.
I think using this property was working round the restriction we had
in the
language at the time in that we couldn't use optional parameters to
music
functions.
At that time one could not use durations as a "native" parameter to
music functions at all. But that is more or less a red herring: at that
time, a _lot_ of functionality was just implemented in the parser
instead of using music functions, and if there had been sufficient
pressure for putting an optional duration with a \times command, that
syntax would have ended up in the parser, anyway.
Come to think of it, \times _was_ already hardwired in the parser
because of the 2/3 parsing and was only turned into a music function in
version 2.15.17, when I made LilyPond fractions have a Scheme
representation.
I really think that unless someone can come up with a really strong
case that
\tupletSpannerDuration is needed for backwards-compatibility we don't
need to
provide \tupletSpan. It was my attempt at covering all the bases in
the
doc-string for \tupletSpan that convinced me. (See below).
Well, it might have been stupid of me to make a user-understandable
syntax and then special-case a geeky value like 1*0 into it. I can
offer two cleaner syntactic alternatives:
\tupletSpan \default
\tupletSpanOff
Since unsetting the property will let any setting in a parenting context
shine through, \tupletSpan \default is not unintuitive. However, it is
longer to write.
https://codereview.appspot.com/7094044/diff/2001/ly/music-functions-init.ly
File ly/music-functions-init.ly (right):
https://codereview.appspot.com/7094044/diff/2001/ly/music-functions-init.ly#newcode1365
ly/music-functions-init.ly:1365: tuplets are being subdivided. To
unset, use a
zero duration like
tuplets specified by the current \tuplet command are to be subdivided.
To
unset, use a zero duration like @samp{1*0}. Doing this will ensure the
spanner
for the music on the current \tuplet command spans all the music,
rather than
the value set to any prior \tupletSpan call.
I think we can agree that we'd rather want a different command or the
\default solution to avoid this technobabble. That was bad thinking on
my part.
Either that, or scrap the property altogether. But there would not be a
good convert-ly rule for that course, and the feature is quite likely to
have seen use.
Of course, we can also just leave the property in place and provide no
user-level command for setting it. But I think even when discouraging
its use, a separate command with a readable presentation will lead to
more readable upconverted scores.
https://codereview.appspot.com/7094044/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
