RE: The MusicXML-challenge

All, 

 

Two things:

1)      If we make big(ger) changes to the standard, we might make it a requirement that conversion (with maybe some loss of detail) is possible between the old and new standard. The advantage is obvious: it gives import/export functionality with older tools that have been abandoned by their writers. A reference conversion tool might be part of the standard? 
The downside of this is that actively maintained tools have less motivation to support the new standard. 

2)      Some technical elements as described by Christof & Peter can be seen as a use case for “enforcing correct notation entry”. It has been highlighted by several people that strong semantics enforcement is key good adaption of the standard. Enforcing the concept of a voice, can (as an example) force tools to attach dynamics to voices instead of just to a measure. (It is the “voice” that sings/plays loud/soft, not the measure. Enforcing this allows for easier splitting/combining of multiple voices in a staff, which is a key element in creating personalized, combined parts as described by Joe.) Requiring it in the standard will encourage notation program developers to implement attaching dynamics to a voice instead of a measure, thereby gently enforcing engravers to do the same. 
Sloppiness both from notation program developers and engravers/composers is in my view the main problem for MusicXML. Tightening the standard to improve that is – for me – a use case by itself. 

 

Regards, 

 

JanR

 

 

From: Joe Berkovitz [mailto:joe@noteflight.com] 
Sent: dinsdag 10 november 2015 15:25
To: Christof Schardt
Cc: public-music-notation-contrib@w3.org
Subject: Re: The MusicXML-challenge

 

Hi Christof,

 

While I cannot speak for Michael, I can helpfully say a few relevant things that I believe the co-chairs agree on:

 

- While it's true that the group's charter (https://www.w3.org/community/music-notation/wiki/Group_Charter) seeks to "maximize investment by developers in MusicXML", this is not the same as requiring a new standard to be 100% backwards-compatible. Rather, it recognizes the fact that the bigger the changes we make, the more work will fall to existing developers to keep up. (Of course, the best changes would also *decrease* the workload for *new* developers.) So there is a recognition that some breaking changes may be necessary for this format to serve a new, broader set of use cases that go well beyond the original archival/interchange role of MusicXML.

 

- As I said to Peter Deutsch, the co-chairs believe it's best to develop use cases before diving into specific technical changes such as chord or voice container elements. However, when we get to the appropriate point, such changes are definitely appropriate to discuss and there won't be any a priori dismissal on the grounds of compatibility.

 

Best,

 

...Joe

 

 




.            .       .    .  . ...Joe

 

Joe Berkovitz

President

 

Noteflight LLC

49R Day Street / Somerville, MA 02144 / USA

phone: +1 978 314 6271

www.noteflight.com

"Your music, everywhere"

 

On Tue, Nov 10, 2015 at 9:01 AM, Christof Schardt <christof@schardt.info> wrote:

Thanks, first, to all contributors and the thoughtful mails.

Michael:
Do I really understand right, that the new established
w3c-process implies, that we do not have to consider
interests of "existing customers and their investments"
(which in the past often was a stopper to sensful proposals).
This would be great news and open the possibility of
substantial improvements and fixes, of which some have
been mentioned by Peter Deutsch. Great.

>From my perspective, I would second two of Peters proposals:

1) The voice must be a structure with a strongly defined
meaning and application.
As of now it has no limits in its application, it could
be some loose editorial annotation. Or a structure making
alement.
Obviously implementors used it according to what a voice
is in their programs. But this was not mandatory.
In fact, you are free to present the notes of a bar
in a messy zig-zag of time and voice, using backup
and forward elements.
I never saw a benefit in that freedom. In the last
consequence it urges the consumer to write an
compicated analyzer for an unordered sequence of events.

In my opinion, the voice is a building block of music.
It is a contiguous sequence of events, notes or rests.
And it should be used in a very strict way.

- a voice starts at bar time 0
- a voice can only go forward
- a voice may have gaps (invisible rests)
- starting another voice implies going back
  to bar time 0 (full backup).
All this of cours on a per measure base.

Things like the raindrop-prelude-example can be expressed
in this way.


2) There is a need for a chord-element as a container for notes.
Peter presented reasons for this, which needn't be repeated.
Nad I can't imagine a program, which wouldn't reflect this
structure in its own data model.


A last word regarding contemporary music and its notation:
A standard without adoption (i.e. broad implementation) is
useless and therefore wasted time. So better ask the potential
implementors.
My answer for example would be: Simply coping with traditional
western music notation is a task of decades, a lifetime task.
>From this experience and perspective, the idea of developing
a spec and implemtation for contemporary notations, is totally
crazy. Of course out of curiousity I once peeked into this domain.
My conclusion: the common denominator is, that modern composers
try to coin each ones personal language, both in terms of sound and
of graphical representation. This is a fundamental contradiction
to the idea of a common specification. Isn't it?

Regards
Christof