Re: MusicDevice instrumentIDs and presets
Re: MusicDevice instrumentIDs and presets
- Subject: Re: MusicDevice instrumentIDs and presets
- From: Brian Willoughby <email@hidden>
- Date: Thu, 19 Jun 2003 03:29:16 -0700
Philippe Wicker <email@hidden> wrote:
[ 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?
I don't think there is anything about MusicDevice AudioUnits which prevents
what you're hoping for. But I may be missing something.
In the physical studio, powering up a hardware sample player or synth causes
the internal circuitry to be initialized to some state before the first note
can be heard. In some respects, that's just like loading a preset or patch,
except that it's automatic, and there's no real patch #. All edits are done in
real-time, and can be auditioned in real-time. Saving to a preset is
optional, especially if the sampler/synth has non-volatile memory for its edit
buffer.
A MusicDevice AudioUnit must be initialized with a preset before it can be
heard, but that should not prevent the user from editing the settings and
auditioning the changes. I don't think there is any requirement that changed
settings be saved to a preset or bank and reloaded before they can be
auditioned, only that the AudioUnit must be initialized before the first sound
can be heard. A user is nearly always going to start an editing session with
an existing sound, and I think that only the existing sound needs to be loaded
from a preset or bank, not each incremental edit.
It even seems possible for an AudioUnit to automatically save the current
settings in the "default" preset so that the in-progress sound design is still
there the next time the MusicDevice is used.
I suppose it may take a bit of code to do exactly what you're after, but I
don't think that the API prevents the feature.
Brian Willoughby
Sound Consulting
_______________________________________________
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.