lilypond-devel
[Top][All Lists]
Advanced

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

Re: [proposal] easy triplets and tuplets - Draft 3


From: Janek Warchoł
Subject: Re: [proposal] easy triplets and tuplets - Draft 3
Date: Mon, 8 Oct 2012 22:44:22 +0200

Hi,

i had some spare time when commuting, so i've written down a few
thoughts on this topic.

First, we shouldn't mix content and presentation.  I think it's a very
important rule; one of the best things in LilyPond is that she allows
to separate music from its layout.

I think that what Joseph suggested is mostly a matter of layout.
Thus, it shouldn't require any additional user input.
For example, displaying the total duration of the tuplet can be done
in an automated way - i'm sure LilyPond can calculate it.  So, instead
of having an additional optional argument that the user would have to
provide, we should just create some property of TupletNumber (e.g.
display-total-duration) that would print these when set to true.  We
could then go as far as to create a function that would evaluate a
tuplet and set this property to true if the tuplet was complicated
enough.
Similarly, deciding what should be displayed inside the TupletBracket
is another layout decision - it seems doable to define several styles
(e.g. denominator only, ratio with slash, ratio with colon, ratio with
noteheads etc) and choose between them using 'style properrty of the
TupletNumber.
Joseph mentioned scores in which tuplet style changes all the time.  I
think that a proper solution to this problem is to create custom
shortcuts for overriding TupletNumber style - this way you still have
layout separated from score (i.e. one can easily turn these functions
off; the layout decisions aren't hardcoded in the music code itself.


Secondly, there is a general design principle which says that
different things shouldn't be too similar.  Because of that i think
that we shouldn't allow \tuplet {} (without ratio argument) to mean a
triplet - it would be confusing (to say the least).

In my opinion, we need a powerful function that can be used to notate
any conceiveable tuplet - that would be \tuplet x/y {}.  In addition
to this, we may define some shorthands, but it's crucial that they are
distinct from \tuplet x/y.  It should be obvious for everyone,
including all LilyPond beginners right from the start, that \tuplet
x/y is THE way to enter tuplets, and everything else is just a
shorthand.


Finally, another cool thing about LilyPond is that she is logical,
precise and the syntax is fairly unambiguous - *unlike* musical
notation itself.  I remember one user writing something like "LilyPond
forces me to write the music in logical and structured manner - if
some notation is particularly difficult to code, i often end up
realizing that it was not a good notation at all".

So, while i'm wholeheartedly supporting intuitive syntax, i also
firmly believe that we shouldn't aim for "the most intuitive syntax
possible".  Some intuitions may be wrong, some may lead to
ambiguities.  Please forgive me for saying this, but in my opinion
musicians are somewhat prone to this "bad intuitions"; some
established music notations are ambiguous for no good reason.  For
example, a lot of guitar music is written in treble clef *without* 8
below the clef.  From my point of view, this is extremely confusing,
and a foolish thing to do.  You gain nothing by omitting the 8 - why
hide the fact that the music is transposed?
In LilyPond, if you use the treble clef without 8, you'll get
literally what you wrote - there will be no silent transposition.  You
have to use the proper (i.e. unambiguous) clef to get what you want
(or you have to use override trickery, but then you know that you're
cheating).  I believe that this quality of LilyPond is very noble.

So, i believe that LilyPond shouldn't always follow her users'
intuition, even if they are professional musicians.  In this case, i
think that \tuplet 2/3 is better than \tuplet 3/2 (for 3 notes in time
of 2), because it corresponds to mathematical ratio, and is similar to
scaling durations.

Whoah, that was a long email.

cheers,
Janek



reply via email to

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