Re: The MusicXML challenge

I strongly disagree that all duration should be total duration. There are many reasons, historical notation, analytical notation, or simply a creative decision, that I would want to show the same duration in different ways (even "wrong" ones). I think MusicXML needs to represent notation, not sound or even engraving. Showing one rhythm notation over another is a matter of notation. This is not the same as specifying positions for symbols, which I would consider to be a separate engraving issue.

Having only one way to represent the notes is a fine goal if you are creating a system for yourself, but if a standard is to be useful, it must be flexible enough to include as many uses as possible -- hence this discussion. :-)

Dave
--
Dr. David MacDonald
davidjohnmacdonald@gmail.com(mailto:davidjohnmacdonald@gmail.com)
David.MacDonald@ucf.edu(mailto:David.MacDonald@ucf.edu)
davidmacdonaldmusic.com(http://davidmacdonaldmusic.com)
soundnotion.tv


On Oct 25, 2015, 3:15 PM -0400, Jamie Gabriel<jgab3103@gmail.com>, wrote:
> Hey guys - I want to second Mogens point about duration! - "let all duration be a total duration". Words to live by!
> 
> Its interesting, as this seems to go to the heart of one of tensions that seems to exist here - on the one hand we need a data format that has timeline right at the centre of it. This can make it explicit as to when musical event take place relative to any other musical event (almost like on off midi type events related to time).
> 
> But on the other hand we want a whole bunch of different things (like mechanisms to break up durations so they look as to be expected on the score. So I don't know, maybe some kind of format is needed where whatever graphical layout items there are, everything should be an attribute of an exact timeline position tag or something.
> 
> I find with MusicXML when I am stripping stuff to build some kind of data set, I will always need to create something like a position-in-bar tag, which is a rational number starting point (in relation to the measure, so a fraction) for any musical even that is happening, and stuff like tied notes or whatever, will just sit underneath this, kind of a like a particular implementation of that position tag.
> 
> Jamie
> http://biodigitaljazz.org/
> 
> On Thu, Oct 22, 2015 at 5:29 AM,mogens@lundholm.org(mailto:mogens@lundholm.org)<mogens@lundholm.org(mailto:mogens@lundholm.org)>wrote:
> > My point of view is the music - not the graphics. (Making a MusicXML player) but ...
> > 
> > About changing the<chord>-command, I would prefer a very simple solution: Remove<chord>,<backup>,<forward>and
> > <tie>-commands (for longer notes). Let all duration be a total duration and do not step the time-division
> > by a<duration>. Add a new command<timestep>to advance the time. This would make it a lot easier to handle notes.
> > Notes to be played under same time division should be specified low to high and<divisions>should be as small as
> > possible - then I could have a dream: That there was only one way to represent the notes!
> > 
> > However - we do have the existing system. We have program code to handle the existing system.
> > 
> > Regards
> > Mogens
> > 
> > 
> > On 2015-10-20 07:51, L Peter Deutsch wrote:
> > > ....
> > > 
> > > The obvious fix for<chord/>is to replace this element with a<chord>
> > > element at the measure level whose children are the notes of the chord,
> > > and to consider carefully which of the current attributes and elements of
> > > notes should be associated only with chords, only with notes, or (in as
> > > few cases as possible) with either.
> > > 
> > > <backup>and<forward>are much worse: they interact with *every* element
> > > that refers to the conceptual flow of time in the score *or* settings such
> > > as margins that may change in the course of the file.For every such
> > > element, the specification must state whether "before" and "after" refer
> > > to the time sequence as modified by backup/forward, or to the sequential
> > > position of the element in the file.Again, a very large red design flag.
> > > ....
> > 
> 
> 
> 
> --
> Jamie Gabriel
> http://biodigitaljazz.org/