openLilyLib (was: Need help creating Scheme functions to automate includes of many scores in a project)

[Urs Liska]

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:

Also, not directly. But you can make it happen.
Basically you have to define some variable in the top-level file, say
#(define is-main-file #t). Then you can check in the included file for
#(if (defined? is-main-file)

That was the general idea I was thinking for a workaround, possibly building on the tag system that already exists.

You may look at this file:
https://git.openlilylib.org/bfsc/das-trunkne-lied/blob/master/library/ly/makescore/compile-segment.ily
which does more or less what you are looking for.
However, I don't know whether that is at all understandable,
especially on its own. But it might give you an idea.

Actually, that was perfectly clear.  Thanks!

Speaking of openlilylib, I have seen you and others recommend it on many occasions.  The openlilylib.org website, though, appears to be all placeholder content. 

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:

• Package/module handling (preventing repeated parsing of packages), that is the mechanism to load modules, optionally with configuration options passed.
• Option handling, a consistent and convenient way to manage configuration options, but also to store data. You can for example write
      \setOption scholarly.annotate.export.latex.use-lilyglyphs ##t
  and create such option paths for custom packages. In fact you also can just include oll-core and use that mechanism in your LilyPond files without actually creating a package.
• Some logging functionality (which I must admit I don't actually use myself).

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.

Since I tend to learn best by example and experimentation, I am perfectly content with cracking open the source for existing packages/modules; but I did not want to overlook any useful design documentation or implementation guides.

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

-- Aaron Hill

_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user