|
From: | Urs Liska |
Subject: | openLilyLib (was: Need help creating Scheme functions to automate includes of many scores in a project) |
Date: | Wed, 27 Jun 2018 08:35:47 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 |
Hi Aaron, thank you for the interest in openLilyLib. Am 27.06.2018 um 00:41 schrieb Aaron
Hill:
On 2018-06-25 22:42, Urs Liska wrote: Indeed :-( This gives me an opportunity to repeat my call for help with this. The website is an Angular application (representing my "state" at the end of a set of online courses), and I got stuck with a practical way of feeding the content in the site. The placeholder content is all "authored" in manually written JSON expressions, which is definitely not the way I want to go forward. So anyone who is interested in making this a usable site and is fluent in the MEAN stack (more concretely, getting data (maybe from "M") into the "AN" part) would be warmly welcomed ... The GitHub for openlilylib/oll-core mentions everything is in pre-alpha state, which does explain things. Unfortunately this is true, and basically because the project didn't really gain traction. Progress is usually been made when someone has a reason to contribute something, usually a package or some functionality for a package. In many cases that someone is me, but there are a few major contributors to different packages. What is missing is a "community" with the intent of bringing openLilyLib into a more generally usable state. Which is a pity because I'm convinced it is a very useful toolkit worth of being more widely known and used. Documentation would be a good start with this - unfortunately at the same time a vital goal, a vicious circle ... So is the only option, then, to just dive into the code at this point? A good starting point would be diving into the usage-examples that should generally be available. They give a pretty good idea of what the packages are about, and when you're interested in the implementation they can also give you starting points where to look at. Then currently the best bet would be to post questions on the lilypond-user list, possibly triggering some discussion and input about what the packages are used for by others and with what success. Would there be a particular subset of plugins (e.g. edition-engraver) that you feel are most representative of the project? That is difficult to say. edition-engraver and scholarLY are maybe the most powerful and consequential packages - but also the most complex ones. Am 27.06.2018 um 01:35 schrieb Aaron
Hill:
That said, what I was seeking was information about openLilyLib itself. How is the project structured? There are two distinct elements. One (historically the origin) is the "snippets" repository, containing self-contained code snippets for a wide range of tasks. This is quite similar to the LSR, with the main difference being that these snippets can be \include-d (instead of having to be copied over to your own code). The newer one is the "package" system, which essentially means that after \include "oll-core/package.ily" further package and/or modules can be loaded through \loadPackage and \loadModule. (BTW: this ensures that modules are parsed only once ...) What services does oll-core provide to packages/modules? Basically, if I were to come up with an idea for an extension to LilyPond, how would I best evaluate whether openLilyLib would make a good platform on which to build and how would I go about integrating it? Generally, if you have some new functionality (for personal or general use) that is conceptually coherent (for example: "tools providing organ registration notation" would be a good package scope while "helper functions for my projects of the last decade" probably less so) it may be a good candidate. Creating a package and setting it up for use (especially when you collaborate and have to tell contributors how to set up their system) requires *some* overhead, but it makes using the functionality cleaner and simpler, so that's the trade-off you would have to consider. The fundamental services oll-core provides for packages are:
Additionally oll-core exports a bunch of functions it needs for its own purposes but that make sense outside of package development too. I won't list them all (that would be the purpose of said documentation ...), but you may have a look at the contents of https://github.com/openlilylib/oll-core/blob/master/internal/os-path.ily, which provides a number of functions that simplify the handling of paths. This is the secondary aspect I have come to find very useful
about openLilyLib and especially oll-core: it encourages
modularization and reuse of code. The functions in os-path are
tools that I need over and over again, and by having them in
oll-core I never have to bother duplicating the code in new
projects. And having such functions available it has become
increasingly clear that it is a tremendous advantage being able to
build functionality on top of existing functionality. This is true
on the low level of Scheme functions but also on the package
level: The edition-engraver is an extremely powerful tool and we
can't thank Jan-Peter enough for having provided it. But the
openLilyLib structure makes it possible to create new packages
that *use* the edition-engraver and provide very simple interfaces
for tools that would otherwise have to be handled in rather
complex manner if you'd directly use the edition-engraver. The
page-layout.conditional-breaks module is a good example for this.
When you want to get an idea how it is to create new openLilyLib package I suggest you have a look at "ji" and "analysis", which both are small and concise. Best Urs
|
[Prev in Thread] | Current Thread | [Next in Thread] |