[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Modularity in lilypond
Re: Modularity in lilypond
Thu, 29 Jul 2010 20:17:38 +0200
My three.5 concerns are:
1) said code cannot use non-public scheme functions (am I right in thinking
2) changes to init.ly 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/init.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 "gregorian.ly" ?
>> 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.
> - Graham