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" <d...@gnu.org> wrote: > Kieren MacMillan <kieren_macmil...@sympatico.ca> 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 _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user