Re: Quit [now definitely O/T]

[Carl Sorensen]

David,

Thanks for your willingness to articulate some concerns.  I think that your
careful thinking can be of real help to the LilyPond community, expecially
if you can help us make things better.


On 11/11/09 7:21 AM, "David Kastrup" <address@hidden> wrote:

> 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.

This is absolutely true.  The objective *is* to make the music entirely
tweak-free.  Unfortunately, we are not there yet.

> 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.

Yes, that is true.  And we understand it.

The challenge is that there are two possible responses to a problem where
LilyPond doesn't do the right thing:

1) File a bug report, and wait for somebody to get around to fixing it
2) Figure out a workaround, which will certainly seem hacky, but doesn't
require waiting for a new LilyPond release.

When option 2 is chosen, we also have the ability to add the hack to the LSR
in order to save it for posterity and allow others to use it.

Unfortunately, when option 2 is chosen, we also lose some of the pressure to
fix the bug in the first place.  Since available development time is
severely limited, we tend not to focus on things that have workarounds.

> 
> 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.

I completely agree with you here.  Your frustration is reasonable.  Part of
it stems from a misunderstanding about the intent of lilypond-internals.  It
is *not* intended to be a tutorial.  It's strictly a reference (think
dictionary, not encyclopedia).  The information you're looking for would
ideally be in the Contributors' Guide or a yet-to-be-written LilyPond
Architecture  manual.

> 
> 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.

Lilypond-extending has not been reworked as part of the GDP (Grand
Documentation Project) which greatly improved the Notation Reference
chapters 1-4.  If you are having a hard time now, you should have tried it
before the GDP.  I have hopes that we'll eventually get Extending worked out
to an equivalent level, but "so much to do, so little time"...

Midi in LilyPond was implemented not as a way to really play the music as
written, but as a way to proof-hear the notes to make sure the notes were
right.  There is no core developer who has MIDI as their primary interest.
Peter Chubb did create articulate.ly to improve the MIDI output (many
thanks, Peter!), but that's hacking the input code, not the source code.  I
don't know of *anybody* who has the expertise and interest to do the MIDI
stuff.

> 
> 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

Yes, so we should add "ritardando" to the index.  A patch is within the
ability of any LilyPond user, and would be speedily applied.

The code to establish a ritardando could be easily written, and may (or may
not) be done as part of the forthcoming GLISS (Grand LilyPond Input Syntax
Stabilization) project.  There's currently some disagreement about whether
it would be good to define

spannerText = 
#(define-music-function (parser location span-text) (string?)
  #{
      \override TextSpanner #'(bound-details left text) = #$span-text
  #")

which would allow above example to be coded much more easily in the input
file

\spannerText "rit."
b1\startTextSpan
e,\stopTextSpan

but would hide the underlying LilyPond functionality (the \override) and
make users less likely to learn how to do overrides that they may need to do
for their own challenging music.

Stay tuned for the GLISS, and get your own opinion in.

Thanks,

Carl