Re: feedback: general thoughts about using LilyPond

[Graham Percival]

On 3/13/11, Janek Warchoł <address@hidden> wrote:
> this isn't meant as a wish-list or a whine-list.

... we go through this every six months or so.

> 1. The single most important disadvantage is that not everything is logical
> (for example hairpin aligning: i must use << {notes} {skips with hairpins
> attached} >> to achieve desired results; this is cumbersome to read, and,
> above all, disconnects objects from themselves (i.e. hairpins from notes
> affected)) and content isn't always separated from layout.

Sure!  So let's change this.  Write a scheme function, something like
\beginCresc #3.0 \endCresc #-2.5  which applies the argument to the
X-offset.  Or maybe make it a bit more "lilypond-ish" and do \endCresc
{ 4..}  to mean "end the crescendo at a duration of 4.. after this
note".

You probably want to quibble about the syntax, but that's not the
important part.  Get a scheme function written first, *then* we can
start arguing about the name, modifying the parser (please no), etc.


I'm always astounded at how much we _could_ be doing with "helper"
scheme functions, but don't.  (some might dismiss them as "syntactic
sugar", but we could keep them as optional includes to avoid
"polluting" the main code base)

In this particular case, I'm guessing 5 hours?  I mean, it'd be like
10 minutes for Neil, but if you're not familiar with scheme and stuff,
it always takes a ton longer.


> 2. There are some frequenly appearing notation elements that still need
> quite heavy manual tweaking, for example:
> - dynamics (often they stick out too much and cause the systems to spread
> vertically)

Are you talking about changing the #'staff-padding, or do you want
lilypond to automatically apply an X-offset and then shift them
higher?  ETA 1 hour for the first (time for discussion), and ETA 15
hours for the second.

> 4. Limited playback (this is very important for my choir - we use midi
> playback to learn our parts at home. Remember that these people have low
> computer skills - learning LilyPond is beyond their capabilities, so they
> cannot modify .ly files to get what they want):

Are you talking about improved MIDI playback (i.e. using Peter Chubb's
articulate.ly, ETA 2 hours to integrate this, and this is one of the
best "bang for your buck" projects that nobody has shown the slightest
interest in), or having actual singing output?

LilyPond theoretically includes singing stuff with Festival, which the
guys in Edingburgh theoretically are working on, but nobody knows how
it works, and festival itself seems not-really-maintained.  I'm a
total uber-fan of Vocaloid singing synthesis (which is non-free) and
Utauloid (which is free as beer but not speech); I've toyed with
making a lilypond => UST file writer -- it _is_ possible to run utau
in wine, although difficult.  But that's very much an aside.

The general topics of "automatic music performance" (and the
highly-related "expressive music performance") are active areas of
research.  If somebody has 2000+ hours, I could mentor them to write a
program which could automatically perform music with another
instrument (say, clarinet).  But that would be worth a Masters degree
by itself, so it probably isn't what you're talking about.  :)


> - there is no visual feedback with midi (nothing that shows in which place
> of the score you are, this is especially important for visualizers),

I thought we had a "karaoke mode" for MIDI?  I know that some programs
do this, so if we don't support it already, adding it would be on the
order of 10-50 hours.

> - starting from chosen measure, or repeating a selected troublesome section,
> is difficult,

Scheme function, 5 hours.

> - they cannot choose which voices play,

Scheme function, 2 hours?

> - they cannot change tempo of the piece.

... oh, sorry, I thought you meant a programmer, not your choir.

> Some of these can be partially solved by using some MIDI sequencer, but some
> problems remain. Also, they are not tech-savvy enough that simply telling
> them 'go use some MIDI sequencer' is a valid answer. I don't like it, but
> that's the way things are.

This really has nothing to do with lilypond itself, though.  We can
produce a MIDI file, and could theoretically produce a .wav file, but
ultimately your choir members would need to be able to use some kind
of software to play it back.

If you have very limited needs (they only need to practice bars X to
Y), then one or two technically-minded members of the choir could
create a .wav file (or even burn a CD!) with that part.  I think that
my mother has burned CDs for one of her choirs, containing a recording
of the music in question on one track, and another track having the
music slowed down to half speed, and another track with the half-speed
for just the difficult verse.

(actually, I don't think she's done that... but if she wanted to, she
could have asked my father to produce such a CD, and he could
definitely figure out how to use audacity)

> 5. Every time Lilypond does something the wrong way i have to learn how to
> correct it. While the documentation is great, it stil takes quite a lot of
> time.

I don't know what you have in mind here.  Better index?  Google
searching of the docs?

> 6. Despite being able to dig through internals, sometimes i still don't know
> if the command isn't working because of a bug or because of my mistake. I
> know i should investigate this and post apropriate bug report if that's the
> case, but i simply don't have time.

and even if you took the time, there's over 500 other problems
competing for people's attention, so it probably wouldn't get fixed.

*shrug*
No solution to this other than "hard work".

> 7. Trial-and-error metods (which are sometimes necessary) are very
> (extremely?) time-consuming because i need to compile the file to see if it
> worked properly.

If you can figure out what kinds of overrides you do often, you could
look into automating that.

> 8. Overrides make code quite unreadable for me. While i'm a little familiar
> with programming, it is still not easy to read; hopefully this will improve
> over time.

Writing custom scheme functions could help with this.

Cheers,
- Graham