Re: The MusicXML challenge and Chords

It seems to me that the resolution to the tension between "innovation" and
"stability" in this case is a standard that is *extensible*.  This means
that the core standards are fixed and stable, but a person/group requiring
additional features can independently develop a standard for those extra
features and use this in conjunction with the existing standard.

This structure would accommodate users with non-standard features in their
music who would still like to benefit from the structures and systems
associated with a standard developed and maintained by a group such as this
one.

For those unwilling or unable to develop their own standards with which to
extend the music encoding standard, I agree that the solution for these
users is graphic software and formats such as PDF, JPG, and so on.  After
all, if a particular graphic score does not have a fixed semantic meaning,
why would one want to use a semantic standard to encode it?

Just a small terminology clarification: The music encoding standard should
be "open" in the sense that it should be available to all (see
https://en.wikipedia.org/wiki/Open_format), but this does not mean that
anybody can make changes to the standard without due process.

Sienna

On Mon, Nov 9, 2015 at 3:25 AM, cecilio <s.cecilio@gmail.com> wrote:

> > Interop requires a strictly defined, closed standard. Even more than
> that,
>
> > user interfaces should encourage or even force composers/engravers to
> enter
>
> > elements in the standard way. A glissando must be entered as a
> glissando, not
>
> > as a line drawing.
>
>
>
> > Let us please first fix the things that are wrong with MusicXML as it is
> and then
>
> > move on to taking in new concepts.
>
>
> Totally agree with Jan Rosseel. And innovation is not a problem: it is
> just new concepts and more features added in future to a well defined
> standard
>
> 2015-11-06 11:44 GMT+01:00 Jan Rosseel <jan@scora.net>:
>
>> Hello all,
>>
>>
>>
>> “MusicXML needs to allow for innovation.”
>>
>>
>>
>> Yes it must from the (modern) composers side of view, and that’s a
>> fundamental problem for what we’re trying to do here.
>>
>>
>>
>> Allowing innovation allows an“ open”  standard where new things can be
>> added without passing by a committee to standardise it first before it can
>> be used.
>>
>>
>>
>> But an open format is a guarantee for interop problems when moving from
>> one application to another, and that’s what MusicXML strives to accomplish.
>> Or at least I hope that’s still the goal.
>>
>>
>>
>> Interop requires a strictly defined, closed standard. Even more than
>> that, user interfaces should encourage or even force composers/engravers to
>> enter elements in the standard way. A glissando must be entered as a
>> glissando, not as a line drawing.
>>
>>
>>
>> If we want interoperability, then we will have to accept that we can only
>> capture the “lowest common denominator”. This is also why Joe hinted in a
>> very friendly manner that MusicXML should probably not try to cover new
>> grounds.
>>
>>
>>
>> But let me state it not-so-friendly, but clear: if MusicXML must succeed
>> as a format for storage and exchange, we can only cover the “normal” music.
>> Normal meaning: music being notated in well-defined ways. Ways that are
>> standard already outside of MusicXML and that are directly understood by
>> the vast majority of musicians. Something should only be considered for
>> adding to MusicXML when it is already a standard way of notating things
>> with pen and paper in a significant part of the musical society.
>>
>>
>>
>> We’ve seen some “ examples”  pass here that required a “manual” with the
>> work on how to read/interpret things. That implies it is not a standard way
>> of doing things even in the musical world, which is why – by definition –
>> it has no place in a standard format such as MusicXML. Constructs that are
>> only used in a handful of works should not litter a standard, and a
>> committee should spend no time on trying to cover it.
>>
>>
>>
>> With my apologies for the ranting, but we must draw a line in the sand
>> for what we want to do, or we will never get anywhere. There’s a perfect
>> format for the more experimental/innovative stuff: it’s called PDF.
>>
>>
>>
>> Let us please first fix the things that are wrong with MusicXML as it is
>> and then move on to taking in new concepts.
>>
>>
>>
>> Regards,
>>
>>
>>
>>
>>
>> *Jan Rosseel *
>>
>> SCORA (www.scora.net)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* George F. Litterst [mailto:glitterst@timewarptech.com]
>> *Sent:* donderdag 5 november 2015 17:50
>> *To:* public-music-notation-contrib@w3.org
>> *Subject:* Re: The MusicXML challenge and Chords
>>
>>
>>
>> Good morning, everyone.
>>
>>
>>
>>
>>
>> On Nov 4, 2015, at 9:11 PM, David MacDonald <davidjohnmacdonald@gmail.com>
>> wrote:
>>
>>
>>
>> Either way, I think MusicXML must be able to show that LH rhythm in
>> whatever right or wrong way suits the user.
>>
>>
>>
>> I agree with David and would like to point out that *right* and *wrong* are
>> constantly evolving concepts in music, grammar, and other areas of life.
>>
>>
>>
>> When a novel concept is put forth, it is often *wrong* by contemporary
>> standards. If the novel idea find wide spread adoption, it later becomes
>> *right.*
>>
>>
>>
>> MusicXML needs to allow for innovation.
>>
>>
>>
>> Regards,
>>
>> George
>>
>>
>>
>> George F. Litterst
>> TimeWarp Technologies
>> "changing the tempo in music software"
>> GLitterst@timewarptech.com
>>
>>
>>
>
>