lilypond-user
[Top][All Lists]
Advanced

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

Re: Quit [now definitely O/T]


From: David Kastrup
Subject: Re: Quit [now definitely O/T]
Date: Wed, 11 Nov 2009 15:21:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Kieren MacMillan <address@hidden> writes:

> Hi Craig (et al.),
>
>> I must say that the "faster" thing is a typical United States
>> behavior.
>
> Whether or not it started in the USA, it's a worldwide phenomenon now.
> =)
> [Disclosure: I'm Canadian.]

It is too cheap to put this down to "faster".  The problem is not that
you need longer to do some things with Lilypond initially.  The problem
is that there is a large number of things for which there is no proper
way to do them at all, and you have to take out the crowbar.

Lilypond is supposed to be a music typesetter.  Music in, glyph
placement out.  If I have to do the typesetting myself, placing glyphs
rather than specifying musical content, Lilypond is not doing its job.
And some Scheme/C++/whatever hackery for manually placing some glyphs
one by one sure as heck is less convenient than just point and click.

The documentation for extending Lilypond is not working out well: the
automatically generated lilypond-internals contains no useful examples
or explanations, the concepts for the C++, Scheme and Lilypond data
structures that one needs for internal programming are not explained
anywhere visibly, it is not clear what one can or cannot hope to do in
what layer and with what level of expertise.

lilypond-extending does not contain examples for the various layers.
There are no examples for how to work in Midi functionality.  As a
side-effect of taking out the crowbar and doing visual arrangement of
music content manually, of course the Midi output does not get any
relevant info.

Things like "ritardando" can't be found in the notation index and are
programmed something like

    Some performance indications, e.g., rallentando or accelerando, are
    written as text and are extended over multiple notes with dotted lines.
    Such objects, called "spanners", may be created from one note to
    another using the following syntax:

         \override TextSpanner #'(bound-details left text) = "rit."
         b1\startTextSpan
         e,\stopTextSpan

PNG image


Not only does it appear ridiculous to have to use a TextSpanner override
before even starting the relevant note just to specify the text (rather
than have \startTextSpan take an argument), naturally nothing will
appear in the Midi output.

There is a lot of things that you can do with Lilypond, but it is
important that Lilypond gets to do more things all by itself (and the
vocabulary to tell it what happens _musically_ so that it will produce
PDF and Midi without further intervention).  If the input for a
facsimile of some historical score is basically indistinguishable from a
modern score input (just differing by how one does everything manually),
something is wrong.

It does not even matter if Lilypond's first implementation/iteration at
doing something sucks: once I can _express_ my musical intent to
Lilypond, future improvements of Lilypond will lead to better output.
But if I can only express a glyph arrangement, improvement is off the
chart.

The mailing list is somewhat helpful, but many of the answers are in the
line of "you can trick Lilypond into showing this/you can hack the
output to be like this" rather than "Lilypond's language for this
musical construct would be".

And that makes you continue your dependence on others' manual help.

-- 
David Kastrup

reply via email to

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