Re: MusicDevice instrumentIDs and presets
Re: MusicDevice instrumentIDs and presets
- Subject: Re: MusicDevice instrumentIDs and presets
- From: Philippe Wicker <email@hidden>
- Date: Wed, 18 Jun 2003 23:56:20 +0200
On Wednesday, June 18, 2003, at 09:31 PM, Chris Rogers wrote:
Chris,
This discussion leads me to ask a corollary question. Some kind of
MusicDevices will allow the user to build instruments and banks "on the
fly" (I think about soft sample players). The user may - will -want to
listen to the result in "real time" without first saving its new
program (instrument) then the instrument in a bank and the whole thing
in a preset and finally reload this preset in the host. When working
with a real (hardware) sample player, you can load, add, remove, edit
samples/instruments and hear the immediate result while sounds are
played. It would be nice if such a behavior was available with any "AU
compliant" host. Most of - if not all - this work is to be done on the
AU side, but as soon as a new instrument is created by the user - by
the mean of the AU custom UI - the host could reflect this change in
its own UI (eg the menu(s) to select instrument/midi channel). Do you
think that hosts should be required (or maybe we could talk of hosts UI
design guidelines) to listen to some parameter/property to achieve that?
Cheers.
A few days ago there was a discussion about the difference between
the use of MusicDeviceInstrumentID and presets in MusicDevices.
It turns out that the MusicDevice API was designed before we had the
notion of presets, so we didn't really anticipate a problem here.
But after discussing this with Bill and Doug, we've decided on a
standard way for hosts and developers to treat MusicDevices.
Presets:
First of all, presets
should be supported by all AudioUnits. A preset is supposed to
contain (almost) the complete state of the AudioUnit/MusicDevice,
and our default implementation saves off the values for all
parameters as well as the state of a few other properties.
Any custom properties affecting the sound should be saved in the
preset.
I think there are some parameters and property values which should
not be saved in the preset, but let's leave this detail for another
discussion.
For some MusicDevice soft-synths, the notion of a preset is all that's
required to describe the sound of the synth. For the sake or argument,
I'll call these kinds of synths "monotimbral" -- there's only one kind
of sound which can be active at a time, and this sound is described
by the preset. For these types of synths, the
kMusicDeviceProperty_InstrumentCount
property should report zero instruments.
MusicDevicePrepareInstrument()
and MusicDeviceReleaseInstrument() don't need to do anything, and could
return an error if called. MIDI patch and bank select messages would
not be implemented because there's nothing to select (the preset
is already set). If someone wants to call MusicDeviceStartNote()
(instead of sending a MIDI note on using MusicDeviceMIDIEvent() )
then use the newly defined kMusicNoteEvent_UseGroupInstrument constant
as the instrumentID.
Other MusicDevices will support playing several different types of
sounds simultaneously on different MIDI channels. I'll call these
types "multi-timbral". These types of
MusicDevices should respond to MIDI patch and bank select messages
when MusicDeviceMIDIEvent() is called. The
kMusicDeviceProperty_InstrumentCount
property should report the total number of patches available in all
banks. And kMusicDeviceProperty_InstrumentNumber should report the
instrumentID given the index 0...n (instrumentID should always be
encoded as bankNumber*256 + patchNumber).
MusicDevicePrepareInstrument() and
MusicDeviceReleaseInstrument() can be called instead of sending MIDI
patch
and bank select. Remember, that multi-timbral MusicDevices still
should
support the notion of presets. Each preset would contain the state of
all the instruments and the patch/bank where they live and the
patch/bank assigned to each MIDI channel.
For the MusicDevice host, unfortunately this requires separate
approaches
to handling each type of MusicDevice. The way to distinguish the two
types would be to call the kMusicDeviceProperty_InstrumentCount
property.
If zero is returned as the count, then it's mono-timbral, and presets
are completely sufficient. Otherwise, there's more detailed
information
and the host can go on to get the instrumentIDs with
kMusicDeviceProperty_InstrumentNumber and their names with
kMusicDeviceProperty_InstrumentName. So, in both cases a host may
want to
present a popup menu showing all the presets for a given MusicDevice,
and for the multi-timbral synths may want to have menu(s) for selecting
the instrument for MIDI channel(s)....
I hope this makes sense to everybody. Please let us know if you think
we've missed something here....
Chris Rogers
Core Audio
Apple Computer
_______________________________________________
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.
Philippe Wicker
email@hidden
_______________________________________________
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.