[MEI-L] Introduction and engraving/typesetting considerations

Sat Jul 5 13:21:55 CEST 2014

Hi Christopher,

thanks for these thoughts!
I can't instantly judge all the implications but it seems there are many 
common aspects and intersections with my ideas. You are right that it 
seems like a *big* project, and there should be thorough discussion 
beforehand.

For example one should think about where such a thing could be placed 
best: as a standalone script, a module in Frescobaldi, a kind of 
"service" etc. (a cool interface could for example be a virtual file 
system, but that's just an un-educated shot in the dark).

But most importantly it has to be thought through how what you described 
with the example of score and parts can be made generic enough to 
accomodate the other MEI-related ideas of providing different views on 
an edition.

I've taken the trigger to create a stub repository on Github 
(https://github.com/openlilylib/mei2ly) - you'll have been notified 
about that already, I suppose.

Best
Urs

Am 05.07.2014 04:52, schrieb 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/
>
>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>

-- 
Urs Liska
www.openlilylib.org