Sequencing the setting of AUPresets
Sequencing the setting of AUPresets
- Subject: Sequencing the setting of AUPresets
- From: Bill Stewart <email@hidden>
- Date: Thu, 17 Jul 2003 23:33:07 -0700
With all of the discussion recently about presets and defining synths
with presets rather than intsruments, etc, I've realised that we have
no "event" type for the Music Sequence to schedule a preset...
So I've added one for Panther.
This allows you to add an AUPreset (CFDictionary) as an event at a
particular time (beat) in a sequence track... Playing the sequence back
will then set the AudioUnits's ClassInfo property with the supplied
preset.
There are a couple of gothcha's with this.
(1) Some AudioUnits will NOT handle this well. For instance, the
DLSMusicDevice that we ship (which is not preset-based in its
implementation) will load a new sound bank when a user preset is set.
This causes the synth to go out to the disk and do a bunch of parsing
of the sound bank file. As the MusicPlayer/MusicSequencer does its
scheduling in the render thread of the graph its attached to, this will
probably lead to an overload...
Whether other AU's generally suffer from this is a matter of testing -
for many AU's this is a very convenient and light-weight operation that
this is a useful operation as it stands (and can reasonably be expected
to be performed in "real" time) - but we won't guarantee that this
event type will work as is for all AU's (nor expect AU's to make any
allowance for this usage)...
A general solution if this is problematic, is to make sure that presets
are set as the first event at time zero for each track (and that these
tracks address different AU's of course!!!) (and that there is only one
preset event pre track).. When the Player is prerolled, it will preroll
preset events up to (and including) the time you preroll the player
too, thus the preroll would prepare the AU appropriately for the
consequent events that are actually "played".
(2) The second question is how the AU responds to the changing of a
preset. For instance, an AU defines its current rendering state by the
value of its parameters... Typically, many AU's will ramp their
parameter values when they change to avoid the zippering and distortion
affects that can occur when those parameters change.
The default implementation in AUBase for the setting of a user (or
factory) preset, is just to set the new parameter values when a preset
is set. Setting a preset can noticeably change the rendering state of
the AU, and thus you can get a "morphing" of the sound from its before
preset state to after the preset is set... This is of course, most
noticeable if the de-zippering takes some time (and wouldn't normally
be heard as a bad thing when a user just changes one parameter or even
a couple)...
After some discussion (!), we decided that rather than "require" or
even "recommend" that AU developers do essentially a Reset when an AU's
preset is set, that we'd leave this up to the particular AU developer
to decide how best to react to this change. (Thus the MusicSequence
will also not call AudioUnitReset after setting the preset as well)...
Thus, I'm posting this just to make developers aware that this (preset
handling) is an issue to consider for their AU's.
Bill
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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.