[MEI-L] Introduction and engraving/typesetting considerations

Andrew Hankinson andrew.hankinson at mail.mcgill.ca
Fri Jul 4 13:34:57 CEST 2014


Hi Urs,

I don’t think I can address all of your points, but I’ll pick out a few and answer below.

I sense we might be talking past each other on the term “Digital Editions” so it might help to clear this up. When I think of the true “digital edition,” I think of an edition that is interactive at its core. It’s not simply a digitally-engraved copy of a piece of paper; it’s an edition where I can interact with it, where I can see the various emendations that have been made to it over time, where I can dynamically re-format it to suit my particular needs (e.g., turn “off” other instruments so that I can focus on a given line). It’s also one where I can link in other representations of the source: audio, page images, bibliographic data.

I don’t know if you had a chance to look at Adrian’s Soundslice system that he sent around, but I think this starts to go towards the general idea. You can dynamically re-size, en/disable voices, and have an audio file linked to the score representation. And, IMO, the engraving quality of this viewer is starting to approach some of the best editors out there.

>> I appreciate someone bringing up the idea of versioned editions. I think that this is one of the biggest advantages of digital editions.
> 
> I'm not completely clear about what you mean exactly. My original point was in using version control as a bread-and-butter tool for daily work. (I think that giving that a try was the most influential decision I have taken in recent years.)
> Of course using that to manage the "visibility" aspect of an edition that is still in progress, or to provide alternative "views" in separate branches is also an important aspect.
> But basically I don't expect these ideas to be of any special interest in the context of the MEI community (the first part of my paper is actually addressed at the "ordinary" musicologists or publishers who have first to be made aware that there _is_ such a thing as plain text and that this _is_ something professional ;-) )

Oh, on the contrary, versioning is something that the MEI community is very interested in, specifically with regards to historical versions of a composition. The ability to encode the content of sources from sketch through drafts to first edition, for example, will be a pretty big part of the digital edition. That’s basically what I meant.

It’s a much different idea of “version control” from what you identified in your paper, but the “digital edition,” as envisioned by many people, will provide an interactive interface that allows you to see different versions as “layers” of a musical work. So, imagine being able to interact with a score of Handel’s Messiah, tracing it through its myriad incarnations through to the first printed edition and beyond. Or a Beethoven symphony from the first sketches to the modern editions. Or enabling a modern composer to preserve the various iterations of their works.

> OK, now it starts to get interesting.
> I wouldn't insist that my suggestions are a one-size-fits-all approach, I think there will always be a trade-off between (human and computing) resources and quality/capabilities. While it is a valid intention to get an edition "up and running with minimal fuss" I think it is an equally valid approach to make an edition "as good as possible". And in my opinion this includes the best possible engraving and typesetting quality.
> In a way I feel reminded of the situation described in http://www.conradiator.com/downloads/pdf/WhatHasWYSIWYG_done2us.pdf.
> When it became possible to do publishing on the "desktop", i.e. on one's own computer people tended to accept severe regressions in terms of quality, say, the total lack of decent paragraph formatting algorithms. Nowadays we are working on automatically visualizing or interacting with encoded content - and in exchange we disregard the tradition of beautiful scores, which is not only a matter of pleasing the eye but also of usability.

The MEI community is, I think, painfully aware that any notation system that doesn’t come with a WYSIWYG editor is doomed to be a niche format. When presenting MEI at conferences to those who we think will actually use it (e.g., performers, musicologists, even publishers) the first question is always “Can I use it in X editor?” (Where the editor is usually either Sibelius or Finale). The response so far has been “Well, it sounds nice, but get back to me when it’s useful for me.”

I don’t disagree with you on the need to produce well-engraved scores, but I don’t think it’s an “either/or” situation here. Given enough computing power it is possible to run something like LaTeX or Lilypond “in the background” and essentially make it emulate a WYSIWYG editor. Up until relatively recently, however, the complexity of the layout algorithms has necessitated a compilation step. Today I think we’re pretty quickly approaching a point where, thanks to multiprocessor systems and high-DPI displays, the difference between the WYSIWYG and the off-line systems will merge.

In short, I think it will soon be possible to have our cake and eat it too.

> (BTW I don't think using LilyPond on a server imposes so much of an overhead. It can easily  be installed (without even needing root access) and can then be invoked from whatever your web application runs from. LaTeX would probably a different beast, even when you determine the minimal set-up needed for a given project.)

I have a bit of experience with client-server communication in a notation editor, and I can attest to the fact that it’s a pretty royal pain in the rear. Simply maintaining a consistent state between the representation that the user sees and manipulates in the browser and the one that is on the server is tricky, to put it mildly.


> I hope that from what I wrote above it became clear that I wouldn't deny the usefulness of client-side engraving with JavaScript or other approaches (although this may also imply significant compatibility issues, now regarding existing older browsers, or regarding future development of web/browser technology).
> But as you say there will still be the need for high-quality visual representations, and I would strongly object to the idea of dropping this altogether (see my previous example about paragraph formatting).

I wouldn’t, for one second, advocate for dropping high-quality visual representations but I think there’s a quality/time investment tradeoff that is in operation for most people. Just like someone who wants to write a little information pamphlet for friends and family doesn’t need to start with purchasing a Lineotype machine and commissioning their own custom typeface from a foundry, I don’t think that those who simply want to put notes on some sort of digital paper want, or even need, to learn a complex engraving system like Lilypond.

Professional engravers will take the time to learn these systems, but most users will not care to learn these systems. If we want beautiful output, it must come with absolutely no impact to usability. Dictating that you must first learning the encoding format first (like MEI XML or .ly) simply will not fly with most people. It’s a battle that we will not win.


> And for the integration of encoding-driven, digital edition concepts with high quality output there's no better choice than the compiling, input-driven tools like LilyPond and LaTeX. If you'd consider the idea of using Finale or Sibelius to automatically engrave scores that have been converted from MEI - then you should have a look at the examples in my paper (p. 22-24) …

I’m pretty familiar with the capabilities of Finale and Sibelius, and although you acknowledge this fact I don’t think your paper contains a fair comparison with their true capabilities.

> The to-be-released scoring program by Steinberg will clearly surpass anything these two programs can achieve, but this wouldn't be any better from the perspective of your "server" considerations (and of course it'll also be a proprietary tool).
> 
I’m actually very happy to have commercial, closed-source applications in the MEI community. Someone *should* be making money off our efforts, IMO, as long as the MEI community and development efforts themselves don’t become driven by commercial interests. We’ll have to wait and see what their end product looks like — for all we know, they’re developing a web-based application as well.

Having said all of this, I really don’t want to discourage anyone from trying. I would LOVE to see a MEI and Lilypond engraving system, and I think many others here would as well. I think the sign of a healthy community is the existence of a bunch of ideas, many of them competing, with an open dialogue between their advocates. 

There are things that *need* to be done, but then there are cool ideas that can be pursued by interested people. So there’s a difference between what the “formal” MEI organization can place its efforts in, and what enthusiastic members of the larger community can provide.

Cheers,
-Andrew


>> 
>>> Dear MEI users,
>>> 
>>> with this post I would like to introduce myself and to open discussion about some thoughts I have written down recently.
>>> 
>>> I am a pianist, musicologist and, let's say: amateur, programmer, strongly interested and involved in musical editing.
>>> 
>>> As a pianist my most worthwile and characteristic achievement is the (first) complete recording of Arnold Schoenberg's songs (http://www.schoenberg-lieder.de and https://www.youtube.com/user/schoenberglieder).
>>> As a musicologist I'm hoping that my soon-to-be-finished dissertation on multiple versions of Schubert songs will add some interesting aspects to Schubert research and editing perspectives (in that I'm recently exploring the inherent fragmentary character of not-so-few manuscripts).
>>> Not a "project" but a finished task is a (printed) edition of the songs of Oskar Fried (http://lilypondblog.org/category/fried-songs/). This is not noteworthy because of the "BEST EDITION 2014" it was awarded but because it was the trigger, framework and testbed for the development of characteristic edition techniques (which starts leading to the actual point of this message). Starting with this project I explore and promote editorial workflows based on plain text, using (mainly) LilyPond, LaTeX and Git (or any other version control system). Over this I have become a central member of the LilyPond community and I think it is interesting to know that nowadays there is someone who can interface LilyPond(/LaTeX) from a user perspective and LilyPond(/LaTeX) from a developer perspective with a serious musicological perspective. To learn more about that part of my work you may browse our semi-official LilyPond blog http://lilypondblog.org.
>>> 
>>> So far I haven't had any concrete experience with MEI, but my participation at the conference on "Digital music edition" which took place in Berne last month was the - long-overdue - opportunity to actively move into the direction of digital edition concepts. As a follow-up of that conference I wrote a paper that you can download at https://dl.dropboxusercontent.com/u/49478835/engraving-in-digital-edition.pdf (this is a non-permanent link and may be removed at any time).
>>> On the one hand it summarizes the two talks I gave, and on the other hand it integrates my existing knowledge with the new perspectives on concretely _digital_ edition concepts I got in Berne. I present it here in order to get some feedback, start discussion, and potentially open up some perspectives.
>>> 
>>> As far as I can see (this is actually a preview abstract of the paper) there still is some lacking awareness for the _quality_ of typesetting and engraving in existing efforts towards digital edition. This is completely understandable as there are so many complex issues to deal with that it's natural to first concentrate on the aspect of _encoding_ and to treat the visualization as a mere necessity. However, I am convinced that _professional_ engraving and typesetting should be an integral part of digital edition concepts too. For example I see that the Reger edition (not MEI, but Edirom based) does contain professional engravings of the authoritative text - but these have been created with an arbitrary notation program and are only available as PDF files in the edition. This is of course against the idea of an "encoding-driven" edition concept. On the other hand I am quite sure that developing custom "rendering engines" can't reasonably be expected to lead to professional results
> 
> in the foreseeable future. However, plain text based tools like LaTeX and LilyPond are conceptually the perfect match for the challenge of automatic typesetting/engraving from encoded content.
>>> 
>>> Therefore I'd argue that it would be better to invest time, energy and money in _integrating_ existing professional tools in MEI/Edirom based toolchains than in reinventing the wheel by creating "rendering engines" from scratch. (Just to say one thing in advance: LilyPond can also be made fruitful for interactive applications, as it can natively produce scores as SVG files).
>>> 
>>> I'd be happy about any feedback on my paper. Particularly I'm aware that the "analysis" of the current state of digital edition (sections 3.1 and 3.2) is the weakest part of the argumentation, simply due to my lack of first-hand knowledge. I hope this doesn't affect my conclusions but I'd be glad to improve the text in this regard.
>>> 
>>> Best wishes
>>> Urs Liska
>>> 
>>> _______________________________________________
>>> mei-l mailing list
>>> mei-l at lists.uni-paderborn.de
>>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>> 
>> 
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>> 
> 
> 
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l




More information about the mei-l mailing list