Re: Questions on data in MIDIPackets
Re: Questions on data in MIDIPackets
- Subject: Re: Questions on data in MIDIPackets
- From: Kurt Bigler <email@hidden>
- Date: Sat, 23 Feb 2002 01:27:37 -0800
on 2/21/02 4:57 PM, Brian Willoughby <email@hidden> wrote:
>
The only thing I wonder is whether percussion timings might benefit from some
>
sort of priority flagging which might allow a group of events to be shifted in
>
time (but not reordered) during heavy traffic jams such that important events
>
happen "on the beat" as closely as possible. But this does seem to be more in
>
the realm of an application instead of the driver...
I'm not sure what you meant by "percussion timings", but if you meant to
exclude keyboard note-on/off events from this category, please don't.
Keyboards need the same timing accuracy as other percussion instruments. (As
Keith Jarrett says, the piano is just 88 drums.)
on 2/21/02 4:42 PM, Brian Willoughby <email@hidden> wrote:
>
longer bits streams such as USB will probably always receive
>
entire packets with a single time stamp.
Lacking knowledge of details here, it sounds like multiple MIDI messages get
packaged with a single time stamp. This sounds unfortunate, unless this
clumping could be done intelligently (e.g. only if the message time
difference is less than the desired threshold of accuracy). Certainly
time-stamp per MIDI message from source to destination would be the
ultimate. No doubt future interfaces will go in that direction unless it
turns out not to matter.
In the mean time designing to allow for timing corrections sounds good, but
it may be hard to anticipate all the consequences, and also in what ways
future MIDI interfaces will be different.
So I hope the Apple design is flexible enough to allow this to evolve, e.g.
by providing for options throughout the MIDI "stack" which have best-guess
defaults, but can be overridden at any level based on information available
to that level, e.g. by the applicaton because the user has told the
application something about the connected devices or how they will be used
that the drivers couldn't have guessed.
The ultimate control belongs with the user. If an application overrides a
driver default, without allowing the user to override that, it is not a good
thing.
And if multi-application scenarios are important as suggested by:
>
To get to my point, if a couple of applications are running off the same
>
timing sync source, then it actually becomes quite likely that multiple
>
clients
>
will schedule events for the same time stamp (e.g. on the beat).
then system-level configuration may be particularly important, lest the user
have to set compatible options separately in several applications via
different interfaces (yuck).
To be very specific: If the user can choose whether and by what heuristic
various drivers may attempt timing corrections (etc.), that might avoid
unforseen trouble that might result from too much driver "intelligence". If
the user can intervene, the driver can be less conservative and risk more
"intelligent" defaults.
-Kurt Bigler
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.