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 > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user > _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user