Re: Quit [now definitely O/T]

[David Kastrup]

Carl Sorensen <address@hidden> writes:

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

Thanks for putting up with me.

> On 11/11/09 7:21 AM, "David Kastrup" <address@hidden> wrote:
>
>> 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.

Perhaps the snippets resource should contain snippets for _future_
versions along with the current snippets.

Not just "here is how you can do this" but also "here is how we wish one
could do this".  And possibly a list of "here are the pieces needed for
that".  Part of that might be better located in the issue tracker.

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

You forgot

3) Work out a proper solution and contribute it.

And in open source software development, that is an option not to be
neglected, because in the end this is the _only_ thing anybody can do
that actually causes things to improve reliably.

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

I have noticed that some of the LSR entries are revolting.  For example,
the diatonic accordion typesetting uses editor macros to
semi-automatically translate music into pseudo-music that happens to
place the tabulature dots in the right locations.

That's pretty absurd since that kind of translation belongs into Scheme.
The resulting source code is no longer transposable, the Midi has
nothing to do with the music, and so on.

This thing belongs in the LSR _only_ accompanied by a task description
of what one would rather be able to write.

It would be an _excellent_ way for _experienced_ programmers to tell
others "what do to eventually" to label ugly hacks as ugly hacks by
spelling out how a nice solution might look in the _source_.

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

What is wrong with
b1\startSpan "rit."
e,\stopSpan

?  Why force meddling with an internal variable in the first place?  You
need the text anyway, why not make it part of the macro?

-- 
David Kastrup