[MEI-L] Introduction and engraving/typesetting considerations

[Christopher Antila]

Hi Urs:

Welcome to the MEI community! (I only introduced myself recently, so a
welcome to myself while I'm at it...)

I've read most of your posts on the LilyPond blog, and I'm proud of the
work you and the LilyPond community have been doing over the past
several years. Moreover, I'm glad to see there are at least two people
interested in how LilyPond and MEI can work together. As I've learned
more about how MEI works, I've realized that it could (and hopefully
will) allow LilyPond users to be more productive by using LilyPond as
what it is: "a music engraving program, devoted to producing the
highest-quality sheet music possible." It seems to me that a fast and
intelligent MEI-to-LilyPond-and-back converter could be very useful for
both communities.

While learning MEI, I've started to realize that LilyPond
users---especially experienced ones---tend to push the program well
beyond what it does well, into roles where it performs poorly (meaning
unintuitively, clumsily, or with many workarounds). You've written about
several of these situations while preparing the Oskar Fried edition, and
James Harkins recently wrote about another such situation.[1] In James'
post, a slur requires different overrides depending on the whether
LilyPond is engraving the full score or just a part. He suggests a
crafty work-around, and one I'll probably use myself, but it's still a
work-around, and it's definitely neither intuitive nor
beginner-friendly. The reason it's clumsy in this situation (as far as I
can tell) is that James is using LilyPond as both an engraving program
and a document-management system. People who prepare the full score and
the parts from the same source code are effectively abusing LilyPond by
pushing it somewhere it doesn't go easily. LilyPond works best when
one .ly file becomes one .pdf file (or .svg, .png, etc.), but text files
work best by avoiding duplication---what an opposition!

It doesn't have to be this way! The primary reason we want to engrave
multiple separate documents from the same LilyPond source file is to
avoid duplicating the code. What if there were a better way to avoid
duplication---one that also handled the score-and-parts situation more
gracefully? I think the solution lies in combining MEI with LilyPond in
a way that allows each to do its best job. I envision a program that
acts as a broker between an MEI file and an ensemble of LilyPond files
(for now, let's call it MLB, "Mei and Lilypond Broker"). This program
would be like git, in that it could be used directly from a commandline,
but it could also be used indirectly through an application such as
Frescobaldi. MLB is also like git in that it would help manage versioned
changes between documents, probably by using git.

Imagine this scenario, where I use my imaginary MLB program alongside a
suitably modified version of Frescobaldi. Since I've been using LilyPond
for more than a decade, I'm comfortable with (and fast at) inputting a
score directly in LilyPond syntax, so that's the strategy I choose when
I'm commissioned to prepare an orchestral score and parts for some new
composition. I start with Frescobaldi's new-score wizard, which
automatically generates LilyPond files specific to each part and for the
whole score, then tells MLB to initialize a project in the same
directory. MLB creates an MEI file that links each of the LilyPond
files, then initializes a git repository in the same directory and makes
an initial commit. Back in Frescobaldi, I start by entering some
measures of the flute part in its part-specific file; when I choose
"Save," Frescobaldi writes the flute part to disk, then tells MLB it's
been modified. MLB reads the flute part and copies the new musical
content into the MEI file, then into the full-score LilyPond file.

After some more work, I've entered all the woodwind parts, and I want to
see how the full score is shaping up. I use Frescobaldi to preview the
LilyPond output from the full score, and I notice a problem: both the
flute parts are written on the same staff, which has caused erroneous
beam directions through several measures. I quickly fix this in the
full-score LilyPond file and save it. (MLB will record this update by
saving the override in the MEI file, noting that it's specific to the
full score). The next time I view one of the flute parts, Frescobaldi
will tell me the part was modified in the full-score file, and use MLB
to show me what would happen if I made the corresponding changes to the
part-specific file too, allowing me to choose whether or not to apply
those changes. Even better, because this is all coordinated with git,
the changes were proposed to me in commit-specific (and therefore
logically-related) chunks, so I was able to refuse the beam-direction
revision but include the wrong note I corrected along the way.

When I've finished inputting all the notes, I want to send it to you for
proofreading, before beautification. Do I have to share the git
repository? Do I have to send you all the LilyPond files? Nope---I just
have to send the MEI file, since it has enough information to let MLB
re-create the full score and all the parts, including overrides specific
to each, and even (potentially) including LilyPond-only markup that
doesn't have a suitable MEI equivalent. After you correct the note
mistakes, you send your MEI file back to me; I use MLB's git interface
to help me integrate your changes.

This hypothetical MLB program is a long way from reality, it's very
complicated, and it's not a one-size-fits-all solution to managing
LilyPond files. However my main points remain: (1) LilyPond is an
engraving program, and MEI can help us use LilyPond better by allowing
us to use it *only* for what it does best; and (2) a dynamic and
intelligent LilyPond-to-MEI-to-LilyPond program could be an important
development for both the LilyPond and MEI communities.

One final remark. Being familiar with his work, I'd like to note that
Andrew is right when it comes to server-side engraving. This does
unfortunately mean that LilyPond (at least at version 2.18) is probably
not the best tool for people who want to do Web-based score editing.
There are, however, many other use cases for LilyPond on a Web server!


Happy engraving,
Christopher

[1]
http://lilypondblog.org/2014/06/slur-shapes-and-transposed-parts-use-tags/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140704/09ecc03c/attachment.sig>