My point when I started this topic was not to change the whole definition of
the \times function. In fact, I think the function works quite well as it
is. I was mostly talking about improving the "interface" - i.e. the words
and the syntax we use to call the functions - to make it more intuitive,
especially for a non-programmer. The \times function was an example among
other. I was proposing to change it to \tuplet x:y, simply because it is
closer to the musicians' language (tuplet), and it reflects more the result
we see and we would write manually (3:2 or 7:5, even if we have 6
sixteenth-notes for the 7:5 in contemporary music).

In fact, if we forget a few little bugs, LilyPond is already VERY powerful
and versatile. The point is not much to improve its features (even if it is
important), but to improve - even maybe rethink - its code entry. Some
symbols, most of the basics in fact, work very well (the notes names (a b
c), the durations (4., 8, 16, \breve), \stemUp, \cadenzaOn, the fantastic
*x/y function, etc.). But the syntax gets hard when getting in
kind-of-Scheme syntax for every tweak, and it changes a lot!

For example, we can write :

\override Voice.Stem #'transparent = ##t
#'(set-global-staff-size 13)
\set fontSize = #14
\override Voice.NoteHead #'stencil = (ly:make-textscript) (?) (which is a
function, why not simply a font character?)

And I am sure to make mistakes!

Just to make functions with a more constant syntax would be a great help for
us, simple users. Like making functions with \ most of the time (inspired by
LaTeX) :

\transparent{Voice.Stem}
\globalStaffSize{13}
\fontSize{14}
\setStencil{Voice.NoteHead, cross} (or even better, \setNotehead{cross} )

or any other syntax, but the thing is to make it constant.

The inconstant syntax to make anything a little outside the ordinary is, in
my humble opinion, the most time wasting feature of LilyPond. The problem is
that we always need to refer to the manual to find the way to write the
tweak, then we always forget how to do it for another score, since all the
tweaks we use have a different syntax.

Also, when doing this, the point would be to keep the names of the functions
as close to the musical terms and to the musical written symbols.

But a little program editor like the LilyPondTool in jEdit makes it much
easier indeed! Maybe that is the solution to the sometimes too complex
syntax of LilyPond.

Also, thanks for the changes in micro-intervals symbols, especially the db
for -eseh!

Frédéric


Note, importantly, that, with the present tuplet syntax, lily handles
all tuplets -- *including broken ones* -- correctly out of the box.
This sort of thing brings Finale and Sibelius screaming to their
knees. (This seems to be an extension of the fact that lily gets one
thing *exceedingly* correct: the duration model of musical time. Out
of the box you can also specify time signatures like 6/15, 5/28, 3/10
and so on, all of which bring other musical notation programs -- with
the the notable exception of SCORE -- to a crashing standstill. Or at
least the last time I bothered to check.)

I've been watching the tuplet discussion with some hesitation. I think
chaning \times to \tuplet is a great idea for the reason that started
the thread: \times is too close to \time. But it seems to me that most
of the suggestions following that initial suggestion begin to confuse
the essential time-scaling function of tuplet brackets (which is their
absolutely core purpose, both in the common practice and now) and
other graphical aspects of the notation such as beaming, grouping (and
even accentuation). Beaming and grouping are terribly important, of
course, but I think that it's best to leave their specification out of
the core tuplet syntax.

More important is to fix the fact that

  \times { c8 d e f }

will currently by default print with only a 4 in the tuplet bracket,
which is mathematically wrong; the denominator 5 must appear.


--
Trevor Bača
[EMAIL PROTECTED]

_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Reply via email to