Re: question about transposing an interval of a 4th

[Carl D. Sorensen]

On 12/22/08 10:21 AM, "Eyolf Østrem" <address@hidden> wrote:

> On 22.12.2008 (17:37), John Mandereau wrote:
>> Le lundi 22 décembre 2008 à 15:14 +0100, James E. Bailey a écrit :
>>> Am 22.12.2008 um 14:04 schrieb John Mandereau:
>>>> Indeed: there is currently no thing in all LilyPond documentation that
>>>> introduces Scheme programming for non-programmers.
>>> And there shouldn't be, in my opinion.
>> 
>> Why not?  I'm sure a not so small amount of users would like to program
>> with LilyPond, so revising and extending the Scheme tutorial is a
>> solution IMHO.
> 
> There are two solutions in the long run, taking two different approaches,
> which are not necessarily incompatible -- in fact, they should be combined,
> but they both call for efforts in different areas:
> 
> 1. Make no mistake about it: using LilyPond IS to be a programmer, to a
> greater or lesser extent. And even though the plain an simple sheets with a
> melody line and a title "just" calls for a scripting language programmer,
> most people will sooner or later want/need to take one step further. Scheme
> is -- at least the way LP works at the moment -- an essential part of that.
> A full-scale scheme-from-the-LilyPond-perspetive tutorial would be nice to
> have, but a less ambitious solution would be a thorough and precise
> description of the INTERFACE between the two ("How does LP use scheme?" or
> "How will an LP user use scheme profitably?"), together with a brief
> description of the most common elements of scheme. I'd add also an outline
> of which things HAVE to be the way they are (because of requirements within
> scheme) and which are "arbitrary" in the sense that they are the way they
> are because of choices made by  the LP developers.

Examples of how LilyPond uses scheme are found in chapter 6 of the Notation
Reference.  I'm currently tasked with rewriting this chapter, but I haven't
got it figured out yet.  Perhaps during the Christmas Break ....
> 
> 2. Minimize the visibility of scheme (and the direct envolvement with LP's
> context properties etc.) by developing a more complete macro layer between
> the user and the backend, the way LaTeX sits between TeX and the user. This
> might probably be done to a large extent with today's LP, but the full
> consequence of this approach would be to modularize LP -- let the core
> program take care of the typesetting mechanics, and make packages for
> Gregorian chant, for harp music, for lead sheets, etc., i.e. for WHAT to
> typeset and for how the user communicates with the typesetting backend. One
> could think of it as an extended and systematized LSR: not just isolated
> examples of how to solve a particular problem, but a system of
> task-oriented packages.
> I'm sure there are disadvantages with this (in addition to the the
> necessary development time), but there are certainly also advantages -- one
> of them being to minimize the need for threads like this one.
> 

This may be possible as far as scheme is concerned, but I don't think it's
possible for context properties.  Until all collisions and spacing can be
automatically resolved, users will need access to the context properties in
order to resolve collisions or incorrect spacing.

Predefined scheme packages are a great idea, IMO.

Carl