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
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