Re: The MusicXML challenge and Chords - graphical notation and basic questions

The point about that Thomas Weber makes about having an XML namespace is a good one. We probably should do that. It will allow MusicXML to be embedded in other documents, which is good for modular use. Then we could have MusicXML extensions in their own namespaces that can incorporate some of these newer notational methods.

But I think this is getting into the weeds. While it is important that whatever standard we set be able to be extended into graphical scores... the fact is that we can't let those concerns override the core necessity of properly representing the much larger body of standard notational scores in an exchangeable, readable, logical format. I say we table the graphical notation discussion for now. We keep it in the back of our heads as we go forward (and we'll rely on Dennis and others who make use of these newer notational methods to make sure we don't completely exclude them), but we need to move forward with basics before we can expand into the full realm of music.

I think we need to answer a couple fundamental questions to help define how we want to represent the notes themselves (which are, after all, the core of what we are after):

1) Does every note described by the MusicXML have to occur at the same or a later time as the ones preceding it in the file? That is, is the timeline the core of the XML specification, or is the core the voices/parts and how they flow together and apart?
2) Are notes the children of staves and measures, or are the measures and staves properties of the note? That is, do we specify in each note that it appears on staff 'x', measure 'y', or do we specify a staff and measure and then define which notes they contain?

For reference: The current MusicXML documentation specifies parts as most important in #1, which is why it has backup/forward and the definition of the "Part" element even in timewise scores. It also specifies that notes are the children of measures and parts, but that the staff is a property of the note.

Everything I've heard so far inclines me toward thinking that we should drop the "partwise" score option of MusicXML, and keep only the timewise option. The number of "Parts" should be a property of the score as a whole (with a default of just 1 part). A Part number should be reserved for true conceptual parts: A melody line and backup chords in a single-instrument piece or each instrument in a multi-instrument piece, for example. Even if a part only shows for a couple measures in the whole score (like a solo, or a short vocal split in a choir), it should be listed at the beginning.

Each measure can specify the number of staves printed for that measure. This allows for part splitting (such as in a 4 part choir piece where there are sometimes two staves for the four voices and sometimes there are 4 staves). At this point the part, staff, and stem direction become separable properties of a note which can be ignored or used by software that is parsing the file, depending on whether they are playing the music, faithfully representing the original, or offering new layout options for the imported piece.

I've stated this before, but I'm leaning toward a measure-based timing system with offsets for each note from the start of the measure. I lean towards not enforcing a strict time policy on the measure level, because it becomes easier to define the notes that have to be tied, slurred or beamed together if you are specifying them as a group rather than trying to keep track of which beam number from the last time-step is associated with the current note. In no case should the time-step in the measure be advanced by a note... each note should only care about its own placement, not affect the placement of the next note.

For those who would like a completely time-wise representation, I would like to point out that the existence of repeats, DS al Coda, or other jumps already makes this impossible without completely deviating from the written score.

--Christina


Christina Noel
Sr. Software Engineer, Musicnotes

Direct:   |  Fax: 608.662.1688  |  CNoel@musicnotes.com


www.musicnotes.com  |  Download Sheet Music
Musicnotes, Inc  |  901 Deming Way, Ste 100  |  Madison, WI 53717

-----Original Message-----
From: Thomas Weber [mailto:tw@notabit.eu]
Sent: Thursday, October 29, 2015 6:34 AM
To: mogens@lundholm.org; public-music-notation-contrib@w3.org
Subject: Re: The MusicXML challenge and Chords - "open commands" - the user/producer is totally reponsible for content, programming and test

Am 29.10.2015 um 07:49 schrieb mogens@lundholm.org:
> Wonder if the problem could be solved by having half open and total open commands (like in Midi).


I fear opening up things too much defeats the purpose of a standard or at least bears the risk that in practice, applications will water it down to an extend it is not useful any more.  However, in some clearly defined cases, I think allowing an application to add their own data might still be considered legit (see below).


> The idea is to move the problems from the MusicXML specification to
> the people doing and using some special construction like notes written in a spiral. Data is hexadecimal data.
>
> E.g. a "half open contruct".
>
> <bitmap PositionType=relative, X=56, Y=56, Rotation=90,
> Type=transparent> 8A6554876F.....</bitmap>
>
> or
>
> <soundfont 8A6554876F.............../>
>
> (Just examples - there is already an <image>-definition)
>
> And a total open construct - the user is reponsible for all the data,
> but must have an account on W3 - the user name shall be identification
> of the user and item. Data is just hexadecimal data.


XML basically already supports everything you describe in the form of XML namespaces.  No need to register a W3C account or anything.  XML namespaces are tied to a URL that is supposed to be controlled by the entity introducing namespaced elements or attributes.  And with those namespaced nodes, there's no need to restrict content to inaccessible hex blobs.  (There's also XML processing instructions which the XML standard defines to be application specific.  They've in fact been used by Dolet, but they don't prevent name clashes by means of namespaces and don't allow structured data, just a string.)

Typical XML consuming applications just ignore the nodes they don't know, so the *only* case where I think such application specific extensions are acceptable would be if it's actually perfectly fine to ignore the additional stuff.

As we were speaking of spirals, I attached an example of how Inkscape defines spirals.  SVG doesn't have a concept for spirals, but of course you can draw *anything* including spirals using SVG's <path> element.  Inkscape preserves all spiral specific information needed for its dedicated spiral tool in a custom namespace.  If you strip all that information, Inkscape (or any other SVG enabled editor) will still allow you to edit the spiral shaped path, but only with the generic path tool, not the spiral tool.

There are however two issues.

* Firstly, while it works in practice, the extended SVG officially isn't valid any more.  It would be possible, though, to provide additional data in a standard conforming way using SVG's <metadata> elements.
* Secondly, the added spiral info isn't just complementing the actual SVG, it introduces redundancy.  If you're editing the spiral's path data outside of Inkscape and preserve Inkscape specific spiral info, the edits to the path will be lost when opening the file in Inkscape again as Inkscape will re-generate the path data if it finds its custom spiral info.

What does this mean for Spiral Galaxy by George Crumb that Dennis Barthory-Kitsz linked[1]?  It is only a spiraled up version of a long continuous staff that, if stretched out, would still be meaningful notation.  As opposed to SVG, we don't expect 100% rendering fidelity from MusicXML.  Assuming MusicXML *was* capable of capturing the notation, be it stretched out or not, then it might be considered legit that an application adds information about the spiral shape as it's not required to make sense of the content.

Extensibility however still is a double edged sword for a standard that is supposed to allow exchange of data.  It's proper use is hardly enforcible or detectable and the problem remains how to avoid inconsistency if edits change the content that some third party metainformation (even if it's not redundant) might refer to.  So instead of this:


> Music notation programs shall preserve this data, whenever possible - but ignore data.
> (unless the program knows how to interpret the data.)
>
> And the originator of the data is responsible for definining the
> structure, accept edited files from common notation programs (not
> crash if a note is added)


it might be safest to strip all unknown information once an edit has been made to a file, if such a thing should actually be allowed eventually.


P.S.:  In any case, MusicXML should definitely use a proper XML namespace, like all(?) the other W3C XML based standards to make them interoperable.  E.g. SVG allows arbitrary content in its <metadata> element.  An SVG file representing music could actually provide a MusicXML snippet in the <metadata> element of each note.  To make this data recognizable as MusicXML, it should be in its proper namespace rather than in the null namespace as it is at the moment.


[1] http://40.media.tumblr.com/b755cf8cd1e90e2151100589c8400850/tumblr_n7g4f8trhG1qbdqqlo1_1280.jpg


--
Thomas Weber
Notabit
Burgkstraße 28
01159 Dresden

Tel.: +49 (0)351 4794689
http://notabit.eu/

Received on Thursday, 29 October 2015 17:36:50 UTC