Re: The MusicXML challenge

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