Re: Questions on data in MIDIPackets
Re: Questions on data in MIDIPackets
- Subject: Re: Questions on data in MIDIPackets
- From: Bill Stewart <email@hidden>
- Date: Mon, 25 Feb 2002 09:58:45 -0800
on 24/2/02 3:54 PM, Kurt Bigler wrote:
>
on 2/23/02 11:50 PM, Herbie Robinson <email@hidden> wrote:
>
> Hopefully, as the legacy MIDI protocol disappears and we
>
> are not subject to the slow transmission times, none of what we are
>
> talking about will matter at all.
>
>
I look forward to that day, hoping Apple is well-prepared. The current OS X
>
APIs still treat the midi "protocol" as "data" rather than logical events
>
(or did I miss something?), which puts us in a position of being not so well
>
prepared for note numbers > 127, floating-point key velocities, and more
>
accurate control values. Also different numbers of notes per octave and
>
alternate tunings are not dealt with well using midi note numbers, such that
>
floating point center-frequency should be able to replace note number in
>
higher-level "MIDI" APIs.
The MIDI Services on X are just that - getting MIDI data in and out of the
system to MIDI Devices (and some IA facilities). How could we possibly
design and implement an API for a protocol that doesn't exist yet and has no
real hardware support?
We also know that MIDI is not the be all and end all of these kinds of
protocols (particularly for Software based rendering) so we specifically
provided APIs for the MusicDevice component (AudioUnit/MusicDevice.h) that
allows for:
Floating Pt note numbers
Floating Pt parameter lists to new notes of arbitrary lengths
Arbitrary numbers of groups (ie. Think MIDI Channels) - where also groups
are NOT defined to be notes on a particular instrument, but are user defined
Floating Pt parameter values
Sample offsets for all of these.
(As well as MIDI APIs)
>
The current APIs do not permit applications to be developed now which will
>
support future changes in the underlining technologies. Perhaps it seems
>
too hard to anticipate a future standard to make it seem worth pursuing this
>
now. Nonetheless I believe many of the next steps (previous paragraph) are
>
obvious. So why not act not and build a software API that _leads_ hardware
>
development?
I might pose the counter question....
When are we going to see tools (sequencers and such) for developers that
whilst allowing for MIDI based instruments, actually provide the user with
far more flexibility and power. There's a lot of this kind of stuff around -
Csound and the like - but it isn't very user friendly (to understate it!)
and doesn't work well with existing work practises of musicians and
engineers.
Bill
>
-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.
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
"Thousands of years ago, cats were worshipped as gods. We have never
forgotten this."
__________________________________________________________________________
_______________________________________________
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.