- From: Sienna Wood <sienna.m.wood@gmail.com>
- Date: Mon, 9 Nov 2015 09:41:08 -0700
- To: cecilio <s.cecilio@gmail.com>
- Cc: public-music-notation-contrib@w3.org
- Message-ID: <CA+sfsQVt8+Vf32tTDSKpfcvQCTWyE7B0wmeLCUZ3ibECu0U24w@mail.gmail.com>
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 >> >> >> > >
Received on Monday, 9 November 2015 16:42:07 UTC