lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Modularity in lilypond


From: Mike Solomon
Subject: Modularity in lilypond
Date: Wed, 28 Jul 2010 16:25:08 +0200
User-agent: Microsoft-Entourage/11.4.0.080122

Hey all,
    I've almost finished moving my vector-graphic package into a module that
is usable by invoking one \include statement (it is in scheme code and .so
files importable by guile).  I decided to do this because the generation of
vector graphics readable by my code uses too much kludgery to really deserve
to be part of lilypond (currently, I can only really work with
Inkscape-generated eps files).  Plus, it makes dependencies a non-issue.
    In doing this, I've realized that almost everything in Lilypond can be
made modular, which is a testament to how well it is put together.  David
had suggested modularity as an option before (perhaps others as well), and
there was a brief flurry of support for this idea: I'd now like to re-echo
it and work seriously on it to make it part of 2.14.  To me, it seems like
the following things would need to be done:

1)  A folder would be created in (ie PATH/lilypond/2.X.X/module) in which
all modules hung out so that Lilypond knew to look there.  Each module would
have its own folder and could be internally organized however one fancies.
2)  A document would be created that invoked all modules that were
perma-invoked.  That is, any module should be able to be called in a given
document, but if the user wants certain modules to be called all the time,
this document should do it.  Ideally, the document would be nothing more
than a series of \include statements.  It would have to have a standard path
that would not get overwritten from version to version (which would likely
involve some copying and pasting combined with some simlinkery).
3)  Certain current features of lilypond would need to be modularized.  This
is probably the most difficult call, as it brings up the question "what
should be part of non-modular lilypond"?  There are certain things, such as
notes, dynamics, and slurs that seem like they should be in any typesetter,
whereas woodwind fingering charts, fretboard diagrams, and harp pedals seem
more modularish.  Of course, the latter things could be shipped with
lilypond and even included as a sort of "automatic module" to make for
backwards compatibility (ie the user would have to decide to delete them
from the document in #2 instead of include them), but I think it'd be
important to modularize as much as possible.

This is likely very easy to set up and test, but as it seems like a
not-insignificant move, I'd want to see first if there is community support
and if there is a group of people willing to iron out how this change could
be orchestrated.

Cheers,
Mike

P.S. In an unrelated note, many thanks to Patrick for his work on the path
command, which will any day now replace the connected-shape stencil - I just
tested a new patch of his and it works perfectly.
P.P.S. It could be that such a modular system already exists and I am simply
not privy to it, in which case I'd appreciate any feedback!





reply via email to

[Prev in Thread] Current Thread [Next in Thread]