Re: Sequencing the setting of AUPresets
Re: Sequencing the setting of AUPresets
- Subject: Re: Sequencing the setting of AUPresets
- From: Urs Heckmann <email@hidden>
- Date: Fri, 18 Jul 2003 22:40:16 +0200
Am Freitag, 18.07.03, um 20:59 Uhr (Europe/Berlin) schrieb Chris Reed:
On Friday, Jul 18, 2003, at 01:33 US/Central, Bill Stewart wrote:
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...
Why don't you make the actual setting of the preset dictionary take
place in a callback fired off of the main run loop? Obviously the
synchronisation gets more complicated, but it would work around this
potential problem for all synths.
Hm. I really like the idea of an extended program change scheme. But
not every device will do this flawlessly, for example if there's
overhead by iFFT stuff or Wavelet things.
Hehe, I've read about a host that generates a black list of buggy AUs
which it doesn't load anymore if they crash. Maybe hosts / AUGraphs
should be allowed to have a black list of AUs that cause serious drop
outs on preset change events?!?
Regarding thread safety, I can think of 1000+ reasons why even the
heaviest state computation should not be interrupted by rendering. If
it has to happen in background, the device should be bypassed until
RestoreState comes back. Dunno how this is commonly handled.
;) Urs
_______________________________________________
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.