lilypond-user
[Top][All Lists]
Advanced

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

Re: Constructive Criticism and a Question


From: Frédéric Chiasson
Subject: Re: Constructive Criticism and a Question
Date: Wed, 3 Jan 2007 00:33:08 -0500

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
address@hidden


reply via email to

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