Re: The MusicXML challenge and Chords - MusicXML is Excellent!

Andrew, thanks for sharing this extremely useful example (Don Byrd is an
old collaborator and advisor of mine, by the way). I think this is a
perfect way to frame one of the key questions about use cases that
confronts this group.

I would encourage us all to avoid thinking in terms of "good" and "bad" as
we consider present standards. All of them have their strengths, but none
of the standards today address all of the challenges in front of us. The
big job we have to do here is to focus on a useful set of problems --
inevitably, deciding not to focus on some of them -- and then craft the
best solutions we can, working from all the ideas on the table from
MusicXML, MEI and elsewhere.

Don Byrd has a wonderful list of "notation outliers" of which this is just
one. Some of them, like this one, lie within what people would think of as
the canon of Western musical literature. Some don't. Either way, this
question comes up: must we allow *all* such outliers to be expressible in
the standard we are designing?

I think the answer *might* be, "No, we don't have to". There is an
inexhaustible supply of notational outliers, as composers will forever
strain at the boundaries of whatever notational conventions apply in their
time. The medium of print imposes no real boundaries but, inevitably, any
semantic encoding will have limits. So I have a feeling that visual
representations (read: image formats) will always have a role in taking
over when a convention-bound set of semantics fail the composer's
intentions.

One final observation: this particular example lies at the well-behaved end
of the spectrum of outliers. But it's a very slippery slope indeed! I think
that MusicXML, whatever its deficits, is at least able to allow cases like
this Chopin piece to be represented as a kind of a visual/semantic chimera.
Part of our discussion should be to re-examine (and perhaps reaffirm)
whether the cost in complexity in the standard is worth this benefit. There
are always other, weirder cases that are not so easy to address.

...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 Mon, Oct 26, 2015 at 11:30 AM, Andrew Hankinson <
andrew.hankinson@gmail.com> wrote:

>
> > ...snip...
> >
> > No, no - stop a while. Remember this: MusicXML is good. It is more than
> good. When I make a MusicXML file using
> > Musescore or Finale and later plays it with my player for Midi and
> MusicXML, I have one MusicXML-file.
> > The same file can be played and be shown graphically in different
> programs and I can edit it. I can make new songs,
> > I can listen to existing song, select my voice and practice using the
> player.
> >
> > MusicXML works excellent combining playing and showing the notes. Midi
> has the problem showing the graphics,
> > PDF cannot be played. MusicXML combines and simplifies working with
> music. And  while I am working with music I
> > do not need to bother about of the implementation details and problems I
> once had programming the player. I can not in
> > any way feel that MusicXML has more focus on graphic than playing - the
> player just plays as if MusicXML was just
> > build for that et vice versa.
>
> This is exactly what I'm saying, but I was going one step further. I was
> reacting to the call for building an "unambiguous" way of representing
> music notation. In my opinion, this is not possible. Music notation is
> inherently ambiguous. If you want to make it unambiguous you need to choose
> which direction you want to go: If you want to build a printable
> representation, a better option is to use SVG or Postscript. Or, if you
> want an unambiguous timing model, use MIDI or OSC.
>
> Within MEI, we've recently been considering the following example
> (provided by Don Byrd), and specifically the lower staff:
>
>
> https://www.dropbox.com/s/xlme3hbvp1cl9jn/Chopin_RaindDropPrelude_MultidurChords.png?dl=0
>
> Semantically, a half-note in a beamed relationship with others and taking
> the same amount of (visual) time as an 1/8th note challenges several
> "rules" about the behaviour of music. You *could* encode this as an 1/8
> note with a half-note notehead, but that then skews the representation
> towards the visual. In other words, a performer would interpret this as a
> half-note held over the underlying 1/8 notes, but encoding it as simply a
> visual change does not then represent this accurately to a performing
> representation like MIDI. A semantic representation would need the
> flexibility to allow a half-note within a beam, and more importantly, would
> need to accurately record a full duration of a 1/2 note in this context
> even though that would take up more "time" than it actually does.
>
> -Andrew
>
> >
> > If we can improve MusicXML - that is fine, but for a user (musician) the
> current issues does not exist.
> >
> > Kind Regards
> > Mogens
> >
> >
> >
>
>
>