Re: The MusicXML challenge and Chords

Good morning, everyone.

This is just a quick note to say that I generally agree with the philosophy that Jan put forth. My company is about to release an application that relies on quality MusicXML data. The hypothetical concept that MXML might go open source with forked branches would be a nightmare for us.

Accordingly, I generally applaud efforts to clarify and improve standards, and I very much look forward to the synergy within the music industry that results from such standards. 

As we go forth, I hope that we can take the approach of building a set of specifications that offer generous boundaries that encompass notational oddities that we see in music from revered composers of the past as well as anticipate contemporary and future needs.

The possible length of a note is a case in point. As a composer, I have no need to write a 1024th note and as a performer I hope that I never have to see one. Nonetheless, I am glad that MXML does not set some lower limit, such as a 64th note, because there was a philosophy in place that suggested that anything shorter that was really unnecessary.

Regards,
George

George F. Litterst
TimeWarp Technologies
"changing the tempo in music software"
GLitterst@timewarptech.com <mailto:GLitterst@timewarptech.com>
> On Nov 6, 2015, at 5:44 AM, Jan Rosseel <jan@scora.net <mailto:jan@scora.net>> wrote:
> 
> 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 <http://www.scora.net/>)
>  
>  
>  
>  
> From: George F. Litterst [mailto:glitterst@timewarptech.com <mailto:glitterst@timewarptech.com>] 
> Sent: donderdag 5 november 2015 17:50
> To: public-music-notation-contrib@w3.org <mailto: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 <mailto: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 <mailto:GLitterst@timewarptech.com>