[Top][All Lists]

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

Re: Modularity in lilypond

From: Mike Solomon
Subject: Re: Modularity in lilypond
Date: Thu, 29 Jul 2010 20:17:38 +0200
User-agent: Microsoft-Entourage/

True that.

My three.5 concerns are:
1) said code cannot use non-public scheme functions (am I right in thinking
2) changes to are not copied from one version of lilypond to the
next, nor are one person's "modules".  I do my compiling from the git
repository, so I could likely rig something like that for my own machine,
but I imagine this is even more problematic for someone downloading a
GUB-made lilypond.  I had this problem with my site-packages when I updated
from Python 2.4 to 2.6, and it took me days to get back things as I had
3) There should be some sorta standard practice (ie template) for how
modules are written (I believe that's what David was referring to).
3.5) I stand by my assertion that certain features of lilypond should be
turned into modules if lilypond is to grow to be as encompassing as
something like j-edit or emacs.  Given the many amount of musics in this
world, if lilypond wants to grow to be as wide-reaching as possible, such a
move seems logical for subsequent versions.

Any ideas would be appreciated!

On 7/29/10 7:47 PM, "Graham Percival" <address@hidden> wrote:

> On Wed, Jul 28, 2010 at 04:25:08PM +0200, Mike Solomon wrote:
>> 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.
> Kind-of like the /ly/ dir?
>> 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).
> Like /ly/ ?
>> 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.
> Like \include "" ?
>> 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!
> I'm not certain if you're aware of the ly/ dir, but if not, you
> should definitely look at those.
> Cheers,
> - Graham

reply via email to

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