Re: The MusicXML challenge and Chords

> 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
>
>
>