lilypond-user
[Top][All Lists]
Advanced

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

Re: Extending LilyPond with packages


From: Jan-Peter Voigt
Subject: Re: Extending LilyPond with packages
Date: Fri, 06 Dec 2013 09:44:31 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.1

Hi Urs and all,

I really have to document, what I did with my packages and what ideas
are behind them. It would need /some/ way to make them a public usable
"product", meaning, it has to be documented and a little bit
restructured, but it has a lot of the mentioned features.

So I try to summarize some of its ideas:

* Calling it "lalily", was a little joke, because it's like la-tex and
it also has templates, wich act a bit like document-classes.
* I always wanted to automatically include my own extensions, so
including "lalily.ly" implicitly include a whole bunch of files -
optionally "once" - in dedicated places inside the lalily folder *and*
the current project/document folder.
* Like the above mentioned templates, I can register layout-, midi- and
paper-blocks by name (in fact it's a list or better a path) and then
register those names for score/book-creation in the dedicated path.
* I have commands, wich produce the actual scores, bookparts or books,
that can act conditionally. For most of that commands, the condition is
"does the parser-output-name match the current file-name?", so it only
happens, if the file is compiled "directly", but not, if it is only
included to store the music.
* Editing the music often means to tweak grobs and to force breaks or
page-breaks. This is done by the edition engraver.
* Sometimes editing means to place a comment/note in the score. Those
comments shall be listed in a file and optionally in a markup-list (at
the end of the file) with barnumber and context identifier. This is done
by a command, wich outputs TextScript elements with an annotation
property. (It might be better to divide Annotation-Grob and tracking the
comments for the list ...)

All these things grew with my own needs/wishes/ideas so they will need
some restructuring/renaming/rewhatever, but I think, there are bunch of
useful things in this context.

The Template mechanism:
-----------------------

A template in this context is a music-function with a signature
(parser location piece options)(list? list?)
The piece argument is a path, technically a list. It points to the
current music. lalily stores a "current music path/folder" before it
enters a template and resets it to its previous state, when the template
function returns.
There are function putMusic <path> <music> and getMusic <path>, that
put/get music in the given path relative to the current path. So if I
have a template that gets its music from #'(violin) and this template is
called with a current path of #'(my impressive music), it gets the music
stored at #'(my impressive music violin)
And I can call another template with \callTemplate <path-of-template>
<path-of-music> <options>. (There are some more ... most scores are for
choir, so I often have to loop over choir-voices/parts)
Now I can composite my music from a dedicated pattern while storing the
music in separate file.
And with my conditional score-creation, I have output for proof-reading
(and hearing) and can savely include this file in a project file, that
collects all music files.

The fact, that the template-music-functions are called in a defined
manner but are actually music-functions means, that on can place
anything in a template.

The Edition Engraver
--------------------

The edition engraver stores the edition modifications, like the music is
stored, in a tree, where each element is addressed by a path
#'(<barnumber> <moment-in-measure> <music-path> <context-path>)
The edition engraver itself receives a path on creation, for which it is
listening. The standard lalily-layout sets on for the current Score with
the current music-folder and one for each voice with any
edition-manager-path of any parent context. Now my templates usually let
every Staff consist of a path, addressing the containing voice, so the
voice inherit it.
The edition-engraver now looks in the (global) tree for elements at the
path #`(,barnumber ,moment ,@path-of-engraver)
and applies them to the context (or the named parent context)

The automatic inclusions
------------------------

lalily looks for files in dedicated folders and in the current folder
and includes them. For this to work it extracts the path from the
location argument (of some music, scheme or void function), normalizes
it (removes all ".." and "." elements) and then appends the relative
file-path. It then does include it with (ly:parser-include-string!
parser "\\include \"~A\"" file-path) (or the like)
If the file-paths are normalized, I can store them in a global list and
look, if I already included them, so I only include them once.

Technical parts
---------------

Most of my scheme-stuff is placed in modules, which can be loaded,
because I extend %load-path with the path to the modules, I created.
No I can simply say (use-modules (lalily lascm)). This is done in init.scm.
This also lead to a bunch of functions, placed in scheme-modules, which
are my personal shortcuts and should better be placed in my personal to
be included files ... I am working on it.
Another thing is: I often use \parserDefine in my include files. This
makes it possible to define variables inside  {}. And I can store them
in a singleton/closure inside a module and reinstantiate those
definitions, if I define vars/funcs in once-included files, but do call
lilypond with more than one include file. If this is a good/clean way
... I don't know. But it works! ;)

-------------------------------------------------

So, this a summary of some of my lalily-thoughts.

Best, Jan-Peter




Am 05.12.2013 22:33, schrieb Urs Liska:
> I'm starting a new thread because the original thread has diversified
> too much already.
> 
> Am 05.12.2013 18:48, schrieb David Kastrup:
>>> For starters, we could take
>>> >https://github.com/openlilylib/snippets/tree/master/templates/predefined-instruments
>>>
>>> > and expand it, and add such predefined "instruments" to official
>>> > LilyPond.  I think it would make "structural" work much easier (esp.
>>> > for beginners).
>> We need to figure out how we can provide "style sheets", similar to how
>> LaTeX makes it possible to define "document classes" (layout definitions
>> and tools) and "packages" (raw functionality packaged into coherent
>> interfaces).
>>
>> Moving in the direction where this is possible also takes some pressure
>> of stable/unstable development and features/fixes: something which comes
>> in its own, optionally used file is not disruptive to the core
>> stability.
> 
> 
> OK, I'll give it a first try.
> Please be aware that this isn't a specification put up for review but a
> first shot to nourish a discussion.
> As a working hypothesis I'll try to take LaTeX and TeXLive as a model.
> 
> Adding the concept of "document classes" and "packages/stylesheets" to
> LilyPond seems a very good idea to me. This would allow a consistent way
> to add functionality to LilyPond without a) bloating or b) compromising it.
> Responsibility for stability and usefulness would be deferred to the
> package author and users, code is only loaded into LilyPond when the
> user decides to need it in a concrete score. I don't think it's a
> problem that users may run into "command not found" problems. This
> equally present in LaTeX, and it isn't really a problem.
> Consequently this would allow us to be much more generous when it comes
> to accept contributions. CTAN respectively TeXLive more or less accept
> any contribution if it
> - is suitably licensed
> - has documentation (not only in binary form)
> - doesn't create naming conflicts.
> There is practically no selection based on quality of code, concept or
> being in line with the preferences of the maintainers.
> I think this could be copied.
> 
> For now I'm concentrating on packages because document classes seem more
> complex, and one aspect should be enough for a first post.
> 
> ----
> 
> Provide a directory structure in the LilyPond directory. This is
> automatically included in the search path and will be searched
> recursively, so I can simply use "myNewPackage" although it's actually
> in the "fancy/engravers" subdirectory.
> 
> Maybe it would be good to consequently accept a parallel "private"
> directory structure (like ~/texmf) where the user can manage his own
> packages or 'install' packages received from others or downloaded
> somewhere.
> This isn't necessary because it could easily be dealt with through
> traditional search paths, but I'd say it's a nice way to get things
> consistent.
> If a package isn't found in LilyPond itself search
> - a default location (e.g. a directory in the homedir)
> - look for an environment variable
> - an include path (or all) specified on the command line
> 
> ---
> 
> One question is whether the library should be included in the default
> installation/download or if it should be made optional.
> Consequently one would have to discuss if one needs a package manager
> like tlmgr.
> 
> ---
> 
> Basically a "package" can provide arbitrary code to be included.
> It can for example provide
> -  overrides to modify the output appearance (classic "stylesheet")
> - new commands / functionality
> - alternative header definitions with arbitrary header fields
> - engravers or anything one would otherwise include too.
> 
> Provide commands like \usepackage and \RequirePackage (naming could be
> discussed) that include the package file.
> Differences to \include
> - search path management (recursive search)
> - allow options:
>   e.g. (in LaTeX syntax)
>   - \usepackage[font="Libre Baskerville"]{mySongbookHeader}
>   - \usepackage[staffsize=17]{beamerLayout}
>   - \usepackage[keep-only-original]{originalBreaks} % ;-[]
>   - \usepackage[console,color,html]{annotate} % (print messages to
> console, color grobs, export html list)
> 
> Optional arguments could be passed as a Scheme alist.
> 
> Maybe it would be good to provide commands to consistently handle such
> options inside the package so one doesn't have to reinvent the wheel in
> each new package.
> 
> ---
> 
> A package should have its own manual like in LaTeX.
> Integration a potentially high number of manuals in LilyPond's
> documentations seems not maintainable.
> 
> ---
> 
> I think one wouldn't need much more as an interface for packages.
> Some of this is also applicable for document classes. But I won't think
> about this right now although I can imagine them to be extremely useful.
> 
> Best
> Urs
> 
> 
> 
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user
> 




reply via email to

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