Re: MNX Proposal now Available [via Music Notation Community Group]

Hi all

I'm not a regular contributor (but a consistent reader of this mailing
list) but I thought I would also reply to this thread (also as a way of
clarifying somethings):

1. I think this issue relates back to a previous post by someone who
mentioned whether CSS should be included as part of the MNX proposal...As
this is explicitly is a 'Markup' language - it is about presentation and
contains view information - not necessarily semantic markup (although I
appreciate it can).  But as such, since bar lines (and any other visual
ways to represent pitch / duration) are specific in a score, that visual
representation should also be explicit in the markup representing it and
not implicitly renderer by the importer (as Adrian has highlighted).

Having said that - the proposal does say "MNX is a proposed music notation
markup standard. Its aim is to improve MusicXML in fundamental ways, while
retaining many of its key concepts, terms and features."  Therefore, is
there a need to separate out whether MNX is aimed to improve MusicXML or to
replace it entirely as a machine-readable / data interchange format and
contain display logic...

Apologies if this has already been discussed and going back over previous
ground.... :-)

Josh

On Thu, Mar 30, 2017 at 3:30 PM, Adrian Holovaty <adrian@holovaty.com>
wrote:

> On Thu, Mar 30, 2017 at 9:53 AM, capella-software Dr. Dominik Hörnel <
> d.hoernel@capella-software.com> wrote:
>>
>> This has practical consequences: In §5.3 (Musical timelines) you state
>> that parent elements should be used as containers to organize child
>> elements, and that it should be easy to alter content of a MNX document.
>> Most music notation editors perform score editing operations like note
>> insertion/deletion on measures: For example, inserting a note into a
>> measure will only affect this measure and leave following measures
>> unchanged. However some editors (like LilyPond, capella, and partly Dorico)
>> propagate changes to the following measures. Now if the score is chunked
>> into measures, inserting a note into the MNX document would require a lot
>> of restructuring by shifting notes between measures.
>>
> Two reactions here:
>
> 1. If MNX files didn't have explicit barline information, then every MNX
> importer would need its own logic for determining where the barlines are —
> a recipe for bugs and inconsistencies, no? :-/
>
> 2. This proposal raises a more fundamental question: how important is it
> that MNX be optimized for real-time manipulation?
>
> You mention LilyPond, capella and Dorico propagate note additions across
> measures — a powerful feature — but I highly doubt they would be using MNX
> as an internal data format. They would most likely be using proprietary
> data structures/algorithms, and MNX would merely exist to import and export
> notation data.
>
> If MNX required barlines, those apps could easily ignore the barlines when
> importing, and those apps could easily generate the barlines when
> exporting. I don't see how a barline requirement would be a problem. But
> since you're developer of capella, please do set me straight if I'm
> overlooking something!
>
> By the way, if we do not unambiguously answer the aforementioned question
> ("how important is real-time manipulation?"), we risk making an
> inconsistent spec. Some parts of the MNX Use Cases document hint at score
> manipulation being important (3.8.4, 3.8.5), but nothing outright answers
> the question.
>
> Adrian
>
> --
> Adrian Holovaty
> Soundslice: https://www.soundslice.com/
> Personal: http://www.holovaty.com/
>