[MEI-L] Introduction and engraving/typesetting considerations

[Andrew Hankinson]

Hi Urs,

Thanks for writing! It’s great to have others thinking about these issues.

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 wondering if you’ve seen an article by Franz Wiering, Tim Crawford, and David Lewis that talks about this. They stop short of specifying specific tools like Git, but the “multidimensional” model they propose is in line with this type of editorial vision. You can access a version of the article here: http://methodsnetwork.ac.uk/redist/pdf/wiering.pdf

One of the biggest advantages of the digital edition is its focus on flexibility of representation, where we can have multiple “views” into a piece to see it in various states of representation, development, and revision. MEI, as an encoding format, supports this but we haven’t yet quite figured out how to render it in a digital edition — although there are several promising prototypes. 

In some ways the focus on the encoding seems counter-intuitive from a musician’s standpoint, since we always start from the visual notation and work backwards to infer the structure, but from a data modelling perspective it make sense to define the encoding and then work forwards to how it gets represented. Having a well-defined encoding allows us to provide multiple views into the data that may, or may not, include the visual representation of the data. For example, in my own work we “render” notation representations to a search engine and analysis system, which bypasses the need for visual representation altogether.

While I agree, in principle, that we should focus our efforts on not re-inventing the wheel, I think there are several realities that we must take into account when imagining the digital edition in the future. The first reality is that the web is *the* platform for delivery. While that pretty much goes without saying, we need to take into account what this means for our development efforts, and the efforts required of our users to get their digital edition up and running with minimal fuss. 

While Lilypond produces gorgeous output, its potential for use in a web environment is somewhat restricted since it requires a server-side component. This would involve some translation layer between the Lilypond system and how users interact with it in their browser. In my experience, this server layer adds a significant amount of complexity to the whole system, not the least of which is that if an organization wishes to deploy this system, it needs to support an entire stack of software on their own servers, which can be Windows, Mac, or Linux of any various flavour. That adds quite a bit of overhead to anyone wanting to just publish their digital edition “online.” 

I think there is a lot of room in the MEI ecosystem for a MEI to Lilypond translation layer, since traditional models of engraving aren’t going away any time soon. In fact, in a dream world we would have MEI import/export to all major notation and engraving systems. But I also think that if we are to try and envision a new approach to creating digital editions then there’s a lot of room to explore new engraving systems that operate in the browser, rather than requiring a server-executed binary. I know JavaScript has always been a bit of a pariah, but it has made great strides in the last few years and it’s showing no signs of slowing down. A JavaScript-based engraving system has the advantage of running on Windows, Mac, Linux, iPod, iPad, iPhone, and Android, without needing any platform-specific code. It also has the advantage of integrating relatively easily with other interesting tools, like audio playback, text representation, and image representation, without needing to “bootstrap” an environment for those.

As for your quality statement, I wholeheartedly agree. Professional digital typesetting is a tricky thing to get right.

I’d be interested to hear your thoughts.

-Andrew




On Jul 3, 2014, at 11:01 AM, Urs Liska <ul at openlilylib.org> wrote:

> 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