[MEI-L] Introduction and engraving/typesetting considerations

[Urs Liska]

Hi Andrew,

thanks for these comments. I hope I'll be able to answer them in a way 
that we can file away most of the issues ;-)

Am 04.07.2014 13:34, schrieb Andrew Hankinson:
> 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 > 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.

No, I don't think we're talking about different things in that respect. 
I'm clear about what you say there. Maybe the misunderstanding is on 
another level. Maybe it's from my background, maybe from the path I took 
towards MEI, but I'm mainly considering "big" projects in the sense of 
the "complete editions", that is projects like editing Reger's organ 
works or the Freischütz in an Edirom edition. This probably affects my 
attitude towards all the complexity issues very much. If you are arguing 
from the perspective of promoting MEI as a foundation for all kinds of 
editorial activity - which of course means getting much smaller 
"institutes" to adopt it - this will of course look completely differently.

But as you say at the end of your message, this is not an "either/or" 
decision, and I don't have the intention to replace everything that has 
already been developed with something new.

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

Yes, this is quite impressive. But I can't tell too much from that 
single example in the context of what we're (or at least I am ...) 
discussing, as that example is far from challenging engraving-wise.


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

Sorry, I see that I was very unclear. Of course the MEI community is 
interested in version control. What I meant is that it's a matter of 
course that you know about it and that you don't need my paper to learn 
in the first place ;-)

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

Apart from the fact that one would have to work strictly in that order I 
can very well see a "traditional" versioning workflow match that 
idea/requirement as well as the idea of "encapsulating" unfinished 
editorial work. Usually you'll agree upon having a "master" branch whose 
characteristic is that it should only contain clean states, i.e. no 
commits that leave the whole in any broken state. Add to that another 
branch that exposes the "public interface" to the edition where only 
those states are merged in that should be visible as such "layers". (Of 
course a very similar thing could be achieved using tags.)

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

Don't need to be told about that ;-) I've been talking about LilyPond a 
lot with basically the same feedback. But that's probably an emanation 
of my initial remark. Everything I'm mainly interested in is probably a 
niche project itself ...

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

What I found very interesting in that respect is my first encounter with 
the Amadeus engraving software (or rather one of its users).
This is software that is out of development for decades but is still 
used by a handful of professionals. It works quite similar to LilyPond 
and compiles input language. But due to the fact that they found a nice 
way to only recomile the necessary parts of a score, and due to the fact 
that we're talking about highly efficient 80s data processing the user 
experience is nearly WYSIWYG.
To some extent I doubt that we'll really get to that level of 
instanteousness because most often the increased processing power is 
accompanied by an increase of functionality and "developer's commodity" 
through additional abstraction layers.

But that's only a side note. Essentially I agree with you that we don't 
have to _decide_ between two approaches.

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

OK, I'll take your word.

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

See above. No objection but probably different perspective.

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

I don't claim to present the "true capabilities" of any of these 
products, I'm pointing out that the _default_ results are so 
significantly different, and that therefore the WYSIWYG tools are a 
rather poor choice when you want to have _automatic_ engraving.

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

This too is a different conception due to different original 
perspective. Of course I don't object that in general. But I would think 
it's to some extent contradictory to create an edition based on Edirom 
and rely on proprietary notation or DTP software for it.

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

Where did you hear that? I'd be interested in that too. But I've been 
following the development quite closely and would somehow be surprised 
if they had something like that in mind.

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

I think I can fully see your point.

Best
Urs

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