[MEI-L] Introduction and engraving/typesetting considerations

[Urs Liska]

Hi Andrew,

thank you for your detailed comments. I will try to get a position 
towards and comment on them as seriously as possible.

Am 03.07.2014 19:31, schrieb 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 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 ;-) )

> 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.

I've read about the multidimensional model but not that particular 
article (is that the one where they develop that model?) From what I 
knew about it I didn't get the "link" to version control, though.

> You can access a version
> of the article here: http://methodsnetwork.ac.uk/redist/pdf/wiering.pdf

Unfortunately this doesn't seem to load, and I didn't find another 
reference to the article.

>
> 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.

That completely makes sense to me (although originally being a musician 
;-) ). This is/was one of the aspects I'm always stressing when 
comparing LaTeX to Word/InDesign and LilyPond to Finale/Sibelius. But of 
course this is much more true when talking about an encoding scheme like 
MEI.

>
> 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.

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.


>
> 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 won't contradict you here explicitly because I don't have sufficient 
experience with server installation or maintenance, and I'm ready to 
accept that _any_ project will turn out more complex than expected.
But again, this is a matter of intent. Someone who wants "to just 
publish" will be more opposed to a complicated set-up than someone who 
cares more about the quality of the visual representation. Also it makes 
a difference if you stress the necessity of instant manipulation on the 
client side or if you choose to offer a restricted number of preselected 
"views". If you expect the users of the edition to (also) print out a 
selected reading in order to use it on the music stand (or if you 
want/have to provide a printed edition too) you will have different 
expectations than if you expect them to mainly browse the edition 
online, possibly to perform "other" i.e. non-visual operations like 
analysis, comparisons etc.

What I want to say is that the quality of the visual representation is 
something that _does_ matter, always, although to different degrees 
depending on the purpose of the edition (I always say: "You can't do 
'no' typography. 'No' typography is usually just bad typography.").
And I would predict that it won't be possible to develop professional 
typesetting and engraving as a by-product to developing digital edition 
tools. Nowadays InDesign offers very good paragraph formatting that can 
match LaTeX's, but Adobe is a whole, commercial company, concentrating 
on this kind of improvements - which is a completely different thing 
than the community of digital music editing.

(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 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.

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).
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) ...
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 haven't thought this through (because that's simply not "due" yet), 
but I can imagine a whole range of options how LilyPond (for simplicity 
I'm restricting myself to music notation) could be positioned in a 
digital edition concept:

a)
Using LilyPond during the edition process to produce a pre-selected 
number of engravings. These can be PDF documents and/or SVG documents to 
enable client-side operations too.

aa)
Additionally LilyPond would be used to prepare (a) beautified version(s) 
of (the) authoritative text(s) targeted for either printouts or a 
parallel printed edition. In that context it may be important to know 
that currently technology is developed (or rather made accessible) that 
allows us to maintain manual layout improvements completely independent 
from the musical content.

b)
Using LilyPond on the server side of a web based edition. Here it can 
generate ad hoc renderings, of course making use of caching where 
possible (and of course also being able to produce SVG).

c)
Deploying LilyPond on a DVD together with an edition.

d)
Provide client-side engraving as optional features of a web based 
edition: Say "if you install LilyPond on your system you will have 
access to these additional options ..."

Of course there are variants of this, depending mainly on the intention 
and target of the concrete edition project.


>
> 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.

Well, I think you had plenty ;-)

Best
Urs

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