Erik Sandberg wrote:
On Thursday 28 December 2006 11:13, Brett Duncan wrote:
Erik Sandberg wrote:
On Monday 25 December 2006 06:32, David Fedoruk wrote:
Hello:
I've been watching this discussion or debate. There are two ways to
look at this problem. The first is from a programmer's point of view
where the programmer is experienced with some computer languages,
these days its upper level languages more and more. For these people,
lilypond typesetting code feels comfortable when it is syntactically
correct and when it makes sense in either computer or mathematical
terms. A mathematical algorithm is what they are used to seeing.
The other group has less mathematical knowledge, very little (very
little compared to a programmer working on a major project like
Lilypond) programming knowledge or experience. In all likelihood the
only thing that connects these people is the printed musical score.
At least in part I think these points have already been made. The
question that occurs to me as a novice Lilypond user (and one who
jumps in the deep end with complex scores!) is this: How will you
deal with other types of prolongation or compression of notes into one
or more beats or where the composers intentions are clear but they are
not immediately mathematically correct?
The example below is a single bar from a Beethoven Piano Sonata (Opus
31 number 3, 1st mvt. bar 53) in which two more out of the ordinary
examples occur next to each other. You will excuse any mistakes in
coding here, this doesn't render as it should.
upper = \relative c'' {
\clef treble
\key ef \major
\time 3
bf16[d f ef] \times 5/4 d16[ ef f g a] bf32[bf a c bf d c bf a g c g
ef]
}
You can see how there are three beams, one for the notes in eaech
beat. The first and second beat are quite clear, but the third one has
eluded me as yet. The score has 12 thirty-second notes beamed together
with "12" below the note heads.
The printed score is clear to the performer. The Lilypond code I
suspect is far more complex. The only way that 12 thirty-second notes
will fit into one beat is if they are triplets, but in context, they
are not played or heard as triplets.
My only comment in this discussion is that the Lilypond code to
represent this short passage should be as clear as the printed score I
am reading.
try \times 8/12 { ... }
(by default, this will probably display as 12:8 above the notes, which
can be tweaked to just show 12)
IMHO, this is an argument for a mathematical notation: You must know what
you are doing to notate the music (i.e., multiplying durations with
8/12), just saying that a 12 should be displayed above would make it
difficult to maintain the .ly code.
Here's a different idea: instead of specifying the ratio for a tuplet or
set of tuplets, what about specifying the duration of a tuplet, and
letting LP determine what number appears over the beam?
For example, where we now use
\times 2/3 { a8 b c }
to get a triplet of three quavers in the time of two, instead have
\tuplet 4 { a8 b c }
LP can calculate the ratio (and hence what should appear over the
tuplet) from the time given before the {...} and the cumulative time of
the notes inside the {...}.
This would mean that users do not need to work out the ratio, they just
need to know how long the tuplet should last. Further to this idea would
be to allow an internal division inside the {...}, so that multiple
tuplets could be entered, maybe something like \tuplet 4 { a8 b c ! c4
a8 ! b8 c4 }. (I've used ! only for explaining the idea - I'm NOT
advocating it as the desired syntax.)
This would mean that for the Beethoven snippet in David Fedoruk's post,
instead of
bf16[d, f ef] \times 4/5 {d16[ ef f g a]} \times 8/12 {bf32[a c bf d c
bf a g f g ef]}
you would put
bf16[d, f ef] \tuplet 4 { d16 ef f g a ! bf32a c bf d c bf a g f g ef }
Just a thought!
Unfortunately, the number above does not always follow from the duration.
E.g., the factors 2/3 and 4/6 are mathematically equal, but give different
numbers. It is probably difficult to define when to use 4/6 and 2/3,
respectively (e.g., I guess {c8[ c16 c c8]} could have either a 3 or a 6
above it, depending on context)
Yes, you're quite correct - I'd overlooked that. So Rick Hansen's
suggestion of a tuplet number function would also be necessary,
But given Han-Wen's post:
Frankly, this discussion has wandered off into bikeshed land. We will
not base typesetting decisions on the form of the \times/\tuplet
argument, for it is incompatible with using identifiers.
I guess there's no point in continuing the discussion.
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
