Re: question about transposing an interval of a 4th

[Eyolf Østrem]

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.

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.



Eyolf


-- 
"A wizard cannot do everything; a fact most magicians are reticent to admit,
let alone discuss with prospective clients.  Still, the fact remains that 
there are certain objects, and people, that are, for one reason or another, 
completely immune to any direct magical spell.  It is for this group of
beings that the magician learns the subtleties of using indirect spells.
It also does no harm, in dealing with these matters, to carry a large club
near your person at all times."
                -- The Teachings of Ebenezum, Volume VIII