[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Notensatz im 21. Jahrhundert] edition-engraver session, Sunday Jan
Re: [Notensatz im 21. Jahrhundert] edition-engraver session, Sunday Jan 19 @ 15:30
Sat, 11 Jan 2020 20:44:57 +0100
Am Samstag, den 11.01.2020, 11:03 -0500 schrieb Kieren MacMillan:
> Hello colleagues!
> I just had a wonderful video-chat with Jan-Peter, as part of the
> preparations for my session “The Edition-Engraver: The benefits and
> limitations of tweaking LilyPond scores” at next week’s
> Rather than simply talk for thirty minutes about how I use the
> edition-engraver, I feel the very best use of this historic
> opportunity — having so many important Lilypond developers together
> in one place at one time — is to dedicate some portion of my session
> time to a discussion/brainstorm regarding the current roadblocks
> facing the edition-engraver, both technically and (to a much lesser
> extent) from the perspective of wider adoption and use.
This is a very good idea, and it is good you brought it up for
discussion. I had a very similar plan with regard to the openLilyLib
presentation on Sunday.
I think the main target audience for the Sunday topics is people who
are very much into LilyPond and its development anyway. Probably there
are random participants, but anybody who stays for another night will
very much have a quite specific reason to do so. Nobody will need to
learn at that point what the edition-engraver or openLilyLib are
> I’m proposing I spend the first 10-15 minutes giving a more-or-less
> traditional presentation: an introduction to the extension/framework,
> examples of usage, best practices when coding with the EE, and so
Given what I wrote above I can imagine you could even reduce that to
not more than 10 minutes by sending example files before.
> Then, in the second "half" of the time slot, I facilitate/mediate a
> discussion — primarily between Jan-Peter and the main Lilypond and
> Frescobaldi development teams — in which we brainstorm how to bring
> the EE to its greatest potential, solve low-level technical issues,
> deeply integrate it in Frescobaldi, etc. The goal of this second
> section would not be to have solved the problems in 15-20 minutes, of
> course, but would just provide a chance for everyone to end up on the
> same page about this powerful tool and how it might move forward.
I would put “solving low-level technical issues” to the bottom of that
list. This is something that may not be too suitable for discussion in
the larger group since (I suspect) nobody except Jan-Peter will be able
to discuss such issues spontaneously.
What I think would be most helpful and making most of the “historic
situation“ would be discussing ways how to get the edition-engraver
integrated in LilyPond. This is raised every now and then, everybody (I
think) agrees to that, but it doesn't really have any substantial
progress. Which is - just like the deplorable state of openLilyLib's
documentation - due to the fact that Jan-Peter won't be able to achieve
that on his own and that never any community effort has gained any
Integration of the edition-engraver in Frescobaldi is another issue
with additional implications. We won't directly support it until it is
integrated in LilyPond. The only way to hard-code edition-engraver
support into Frescobaldi would be to include the code directly in the
Frescobaldi code, as we did with the code for the Layout Control Mode.
But I think everybody will agree that such a fork (which it would
effecitvely be) is a terrible idea.
However, there is one road that can be pursued, and that is
Frescobaldi's new extension API. I plan (have already old code that
could be adapted) to create an openLilyLib extension. This will allow
the Frescobaldi user to directly download, install and manage
openLilyLib and its packages and should also provide tools (shortcuts,
context menu items and maybe something like the Quick Insert Panel) to
simplify the inclusion of openLilyLib (a GUI for selecting and creating
the package loading code).
On top of that (but I haven't thought this through) that basic
extension will provide an infrastructure/API for *other* extensions
that may be added for specific packages. The prime use case *I* am
thinking of will be the scholarLY package, i.e. an annotation
editor/viewer. But such a package for the edition-engraver will also be
> Jan-Peter is on board for this approach. How does it sound to
> everyone else? Please let us know if you plan to attend, and if so
> whether you’d be an interested/willing participant in a
I think the above makes clear that I'm very much in favor of your
suggestion. However, I suggest we reorder the program for Sunday, and I
think it's not an issue to do that at this point. Regardless of the
actual points in time the three slots should be in the order
Frescobaldi => openLilyLib => edition-engraver. The Frescobaldi part
will introduce the extension concept, and openLilyLib is the framework
in which the edition-engraver operates (and any discussion about its
future should build upon the discussion of openLilyLib's future).
The easiest way to accomplish this would be to simply rotate the three:
The distinction in the morning session as "varia" and the afternoon as
"Frescobaldi and LilyPond" seems quite arbitrary anyway.
What do you think?
Especially Werner, did I overlook anything regarding changing the order
of the programme?
> Really looking forward to seeing all of you next week!
> Kieren MacMillan, composer (he/him/his)
> ‣ website: www.kierenmacmillan.info
> ‣ email: address@hidden