Re: Chords in the MIDI API?

I think that this doesn't provide as much convenience as it might seem,
which is why it isn't seen in most MIDI implementations.

For incoming MIDI the timing of a human performance is very irregular at a
small time grain and different apps infer "intended simultaneity" with a
wide variety of algorithms that can deliver different results about the
nominal time of a chord, or whether it even is one, or whether it was
rolled up or down, etc. Better to leave this to JS.

For outgoing MIDI typically one will pregenerate a set of timestamped
events stretching into the future a short interval and let the low level
driver do all the scheduling. So simultaneous timestamps suffice to cause a
truly simultaneous chord that doesn't depend on latency in the higher
layers of the architecture.

...j
On Feb 9, 2012 4:29 PM, "James Ingram" <j.ingram@netcologne.de> wrote:

> I'm wondering if, for convenience, Chords could become part of the MIDI
> API.
> ChordOns would simply be a list of NoteOns which are conceptually
> synchronous (received or sent within a very short time span). Similarly
> with ChordOffs.
>
> My experimental AssistantPerformer [1] software uses a span of 12ms to
> collect input NoteOns and NoteOffs into such packages. These are much
> easier to program with than single notes.
> As I remember, I arrived at 12ms by trial and error, so this obviously
> needs discussing. Has anyone got a better idea of where the threshold
> should be? Maybe it should also be exposed in the API?
>
> all the best,
> James
>
> p.s. I'd like to add that I am currently working on a cleaner and leaner
> version of my software, which I'm hoping to publish as open source software
> soon. The patch editor has gone, but the notation and performance software
> have been enhanced.
>
> [1] http://james-ingram-act-two.**de/moritz/**
> moritzAssistantPerformer.html<http://james-ingram-act-two.de/moritz/moritzAssistantPerformer.html>
>
>
>
>