Re: Measure-free scores

> I would much rather that an application export multiple measures with
hidden barlines that decide not to support MNX at all.

It would be deceptive to finally find that MNX results in cosmetic version
of MusicXML. Most current existing applications uses the 'hidden' barlines
approach probably as a bypass, because they put the emphasis around
measures without considering the existence of measure-free music. Even in
these cases, it should not be complex to export music in both formats,
single measure or multiple measures with hidden barlines, so I do not
consider that enforcing a single construct will force people not to support
MNX. On the contrary, I think that a clean approach not open to
interpretation or multiple alternatives will be a stronger standard.

Hidden objects has to do with presentation not with the semantics. Having
to deduce that an score is measure-free by checking that all barlines are
hidden and that there is no time signature is not an advance over MusicXML.


On Mon, Apr 3, 2017 at 6:38 PM, Michael Good <mgood@makemusic.com> wrote:

> Hi all,
>
> One of the main ways that MNX differs from MusicXML is in its addition of
> hierarchy. You can see the rationale for this in the discussion of musical
> timelines in section 5.3. One of the motivations is to make it easier to
> manipulate musical content using a document object model.
>
> Moving measures out of the hierarchy in the CWMN profile would work
> against these MNX goals. We are representing common Western music notation
> here, and measures are a central concept in that system.
>
> We do want MNX’s CWMN profile to be able to represent multi-metric and
> non-measured music, just as MusicXML already does. Perhaps we can find a
> better solution for multi-metric music in particular than what MusicXML
> offers. But we do not want this to come at the expense of representing the
> vast majority of Western notated music written and performed not just
> through 1900, but through 2017.
>
> I believe that we need MNX to maintain MusicXML’s high focus on usability,
> both for developers and for people reading the XML document and matching it
> to a printed or displayed score. MNX proposes solutions that aim to
> increase usability in both areas. Removing measures as a container object
> would seem to move us in the wrong direction.
>
> Along those lines, I would like to avoid mandates for things that may be
> impractical for many applications. The “one big measure” approach to
> unmeasured music seems like it would be the recommended approach for MNX as
> it is for MusicXML. But if that is not practical for an application to do,
> I would much rather that an application export multiple measures with
> hidden barlines that decide not to support MNX at all.
>
> Sometimes MusicXML may have carried this philosophy of avoiding mandates
> too far, leading to more complexity for most applications. So there is a
> balancing act involved.
>
> Since I saw references to page and system objects in this discussion, let
> me reiterate that MNX, like MusicXML, is primarily a semantic format. Pages
> and systems would be out of place in the MNX CWMN hierarchy as they are
> expressions of a particular engraving appearance.
>
> Best regards,
>
> Michael Good
> VP of MusicXML Technologies
> MakeMusic, Inc.
>
> On Apr 3, 2017, at 7:38 AM, Christof Schardt <christof@schardt.info>
> wrote:
>
> Joe:
> I would add one more point here: measures are tangible objects in the user
>
> Jan:
> It would be really awkward to ignore this real-life concept in MNX.
>
>
> +1 !!!
>
> And last not least don't forget to consider practical aspects:
> inspecting MusicXML-files in xml-editors with hierarchical
> code colding would be a pain, if this structuring element
> would be flattend out.
>
> The measure-provided correspondence of tree-nodes in an editor
> and sections in a score is an invaluable help.
>
> I regard measures as a main structuring element of 99.5% of the
> files we have to handle.
>
> Christof
>
>
>
>