[MEI-L] MEI for long-term preservation

[Roland, Perry (pdr4h)]

Hi again,



Look below for the latest message in the MusicXML list thread I mentioned earlier.



I think Andrew does an excellent job here of pointing out specific benefits of MEI so I won't attempt to embellish his remarks.



Interesting questions raised by the messages Andrew is responding to include



- What is the definition/nature/usefulness of a "comprehensive" representation?

- Can an XML representation function as the "native format" for a notation editor?

- Is it possible to create a conceptual model of notation that editors can share even if they implement it differently?

- Can different notational "styles" (Neume, Mensural, and CWMN) be accommodated by the same model?

- If not, why not?

- What role does "validity" play in a notation format?

- Can there be different notions of "validity" at the same time or at different points in the lifecycle of a notated musical object?

- How can a model be "interchange-able" and extensible at the same time?



And probably at least a thousand more.  :-)



I'm aware that attempts to answer questions like these can seem like discussing how many angels fit on the head of a pin (or "pin-headed angels" as we refer to them at UVA).  But these are precisely the questions that most need answering and MEI (again, the format and the organization) can address.  MEI's rise has not been as meteoric as that of MusicXML, nor is it as widely known, but I think MEI is in a position to confront and resolve these thorny issues at least as well as other approaches and probably better due to its design and the people working on it.



Best wishes,



--

p.





> -----Original Message-----

> From: Andrew Hankinson [mailto:andrew.hankinson at gmail.com]

> Sent: Wednesday, March 05, 2014 2:56 PM

> To: musicxml at makemusic.com

> Subject: Re: [MusicXML] Library of Congress data challenge

>

> Any attempt at creating a "standardized" archival format for music notation

> should also take into account that music notation itself is not standardized.

> There are as many exceptions as there are rules in music notation. Don Byrd

> maintains a list of what he calls "extremes" even within Common Music

> Notation itself [1] that would be a challenge for any representation to store

> in a structured and comprehensive manner. Even beyond these extremes,

> there are hundreds, if not thousands, of examples of music notation that

> feature unique symbols, or symbols that have different meanings, or circular

> staves, irregular rhythms, and strange performance instructions.

>

> I believe this is why some communities *choose* not to use MusicXML, as

> noted by Michael himself. Since MusicXML is an interchange format

> specifically designed for representing conventional Western notation

> between CWMN editors, it excludes many other systems of notation that,

> while not as popular as CWMN, are still important to the communities that

> work with them. Musicologists may choose to pursue other formats since

> the implicit meaning of the notation in non-measured mensural music in

> pre-modern musical works is fundamentally incompatible with structures

> for representing modern notation when you're talking about ensuring that

> the encoding is faithful to the notation and the music, and not necessarily

> to the structures required by the file format.

>

> In other words, choosing any single non-comprehensive format as a long-

> term archival format excludes the storage and representation of certain

> musical materials. That's what makes this problem such a tough nut to

> crack. Having software that reads and writes notation files is but one edge

> of a two-edged sword. The other edge is ensuring that the representation is

> faithful to the structure of the notation itself, in whatever form it was

> meant to take. You cannot faithfully represent the underlying musical

> structures of Gregorian chant in a system (any system) designed to

> represent CWMN, or vice versa. Your choices are to either create a system

> so generic that you represent the lowest common feature (e.g., pitch and

> duration, which is what makes MIDI so flexible but not so expressive) OR

> you choose to focus on accurately representing some features at the

> expense of not representing others (which is what makes formats like

> MusicXML expressive, but not always flexible).

>

> [1] http://www.informatics.indiana.edu/donbyrd/CMNExtremes.htm

>

>

> On Mar 5, 2014, at 2:11 PM, David Webber <dave at musical.demon.co.uk<mailto:dave at musical.demon.co.uk>>

> wrote:

>

> > From: Mogens Lundholm

> >

> >> A very interresting and important discussion. My point of view is that

> > music-xml should be the native format of music-writing programs and

> > players and readers. I.e. you should be able to open and save

> > directly - no import and export (MuseScore is terrible). If some thing is

> > missing in Music Xml, then add it. <

> >

> > Unfortunately this will not work.

> >

> > 1. Software designers design their software very differently, and for

> example Mozart's internal representation of notation is very different from

> that of MusicXML. (And I'm sure this is true of other software.)  So for

> import and export a time consuming conversion is done.  This would not

> work for everyday saving and loading of files.

> >

> > 2. There is all sorts of non-obvious information that programs can store,

> which MusicXML doesn't - and for general purposes probably doesn't want

> to. For one arcane example: Mozart has a number of anchor points on the

> page. The 'Composed by' text is anchored to a point at the right margin just

> above the music, which is to say it knows that this is its anchor point and it

> knows how far away from that point it is.   You can edit the right margin

> width and the top margin, and this text entry automatically just stays where

> it is relative to the top right of the music.  Other text entries (title, header,

> footer, and other miscellaneous text) have other anchor points. MusicXML

> just stores a distance from the bottom left of the page.   When importing, I

> know where on the page any piece of text should go, but not where it

> should best be anchored.  I wouldn't expect to demand that all other

> programs should define and use anchor points the way I do, and so I

> wouldn't expect MusicXML to store this information.

> >

> > 3. You can't expect developers to wait to improve their programs until

> requests to the Finale people (a competitor!) get exactly the right nodes

> added to the MusicXML spec.

> >

> >> Davids comments are very intreresting - I also had my fun with the

> > <backup>-command. And do not like the <tie>-command. But now

> > these problems are solved, so this is past.<

> >

> > Solved for me too, but it took a lot of code!

> >

> >> Midi could work - but  unrealistic to collect people to define

> > approvements. Just look at the attempt described in the book "Beyond

> Midi"

> > to define a command for Clef.<

> >

> > Yes - MIDI isn't and never was a notation format.   It doesn't even have

> crotchets and quavers: just notes which last so many milliseconds and have

> gaps in the sequence for articulation (or overlap).

> >

> >> I like the idea of a Music XML format checker: There must be a title,

> >

> > Why?   Some people just want to save untitled jottings in files.

> >

> >> there must be names on the voices/instruments, verse lyrics must be

> numbered

> > 1,2,3,4,5 etc, <backup> must be within song.

> > Also there should be number of test-files that a program must pass.<

> >

> > Why?  Suppose you get a MusicXML file which doesn't pass the test?  Do

> you just put up a sign saying "Sorry this file is illegal" or do you do your best

> to import it and get it maybe 95% right?  I would argue the latter. [It would

> be nice to test for legality but not, I think, essential.]

> >

> >> The next statements are obvious - but nevertheless not according the

> any

> > music program I know

> >> ...

> >> 2. If the program can change a Music XML file, it must preserve

> >  commands not known to the program

> >

> > This is not possible.  If you edit a piece of music, then some of the things

> stored in the original, which you didn't know about, will have become

> implicitly invalid.  You cannot know which or why, and so you cannot re-

> export them and expect a valid MusicXML file.

> >

> >> ...

> >

> > So, in summary: nice try but I'm afraid this can't work.  While someone

> might rise to the challenge of writing a program for which MusicXML is the

> native format, that is quite a different proposition from trying to write the

> best music editor you can.  This is why MusicXML will always primarily be an

> exchange format.

> >

> > Dave

> >

> > David Webber

> > Mozart Music Software

> > http://www.mozart.co.uk/

> >

> > -----------------------------------------------------------------------------

> > Post your message to the list by sending it to musicxml at makemusic.com<mailto:musicxml at makemusic.com>.

> >

> > To contact the list owner, send your message to

> >     musicxml-list-owner at makemusic.com<mailto:musicxml-list-owner at makemusic.com>.

> >

> > To unsubscribe, switch to/from digest, get on/off vacation, or change your

> email address, click here.

> > <http://cgi.mail-<http://cgi.mail-list.com/u?ln=musicxml&nm=andrew.hankinson%40gmail.com>

> list.com/u?ln=musicxml&nm=andrew.hankinson%40gmail.com<http://cgi.mail-list.com/u?ln=musicxml&nm=andrew.hankinson%40gmail.com>>

> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20140306/34a02e4f/attachment.html>