Re: AudioUnitPropertyMigrate question
Re: AudioUnitPropertyMigrate question
- Subject: Re: AudioUnitPropertyMigrate question
- From: William Stewart <email@hidden>
- Date: Mon, 14 Jun 2004 11:59:29 -0700
There's no inconsistency here... just a need to code correctly (though
I will admit some vagueness around the use of the class description
that I will clear up and post)
>
>>
The host then constructs a CFDictionary from this preset by adding the
original plugin preset data to this dictionary with the appropriate
key/value paring:
Plug-in Type Key Value
CFString CFDataRef
MAS "masdata" MAS preset data block - see addendum for details
VST "vstdata" vst preset data block - see addendum for details
A valid aupreset dictionary is required to contain a number of
predefined key-value pairs. In this case however, the dictionary that
is given to the plugin need only contain one of these keys. It is *NOT*
valid for an Audio Unit to return a dictionary that just has this
"***data" key-value pair in it (though it can retain that entry for
compatibility or its own usage).
>
>>
The idea here is that this is *not* an AU Preset - but represents a way
to establish an AU state from a preset in another format (vst or mas).
The normal keys that are defined in an AU Preset (type, etc...) are not
applicable when this is being set, as the only way to validate that the
preset value is actually valid is dependent on the internal data
definitions of what is defined by either a vst or mas preset....
So, rather than have a separate property for this we re-used the class
info property and made it valid for an AU to be set (we DO NOT accept
this as a valid way for an AU to SAVE its preset state) where the only
contents of the class info dictionary maybe one of these entries.
Your AU should accept this if you are supporting translations from
other formats.
The CA-SDK does not contain any implementation that supports this -
however it is simple enough to implement - You'd already have an
overide to the AUBase::RestoreState method - so its up to you to
validate the dictionary you are passed in.
For instance, I could imagine most people could use the following logic
(type here is the AU Preset entry for the AU's component type)
OSStatus MyAU::RestoreState (inDict)
{
if (inDict.HasKey (vstdata) && (false == inDict.HasKey (type)) {
// you are being set with just VST data, no AU data, so the vstdata
is the thing you should trust
return noErr;//!!! hopefully! :-)
}
// if you get to here then you may/may not have vstdata, but you DO
have a valid AU Preset dictionary
// in that case you have to trust the data in the dictionary that you
know you can trust, based on what you save normally
// so, first step would be to call AUBase's implementation to validate
the preset
OSStatus result = AUBase::RestoreState (inDict)
if (result) return result;
/// yadda, yadda, yadda...
}
By doing things this way, we've also ensured that an AU can never save
its state in any other format than a valid AU Preset dictionary.. which
is important for the way that host's can match presets to AUs (see
AudioUnitHosting for an example)...
Of course, an AU can stored valid "vstdata" or "masdata" in an AUPreset
as well, and a host could easily extract that from an AU Preset and use
it with the vst or mas version of the plugin if it so desired... (and
the vst or mas versions of an AU could also use an au preset as a
source of information for presets in non-AU worlds as well for that
matter)...
Bill
On 14/06/2004, at 9:40 AM, Marc Poirier wrote:
>
In the AudioClassDescription within the AudioUnitOtherPluginDesc, I am
>
wondering what to do with all of the fields when I want to describe a
>
VST
>
plugin. VST plugins don't have manufacturer IDs, so I'm not sure what
>
to
>
do with the mManufacturer field (just set it to zero?). Basically VST
>
plugins just have one "unique ID" value, and I'm not sure if I should
>
use
>
mType or mSubType to hold that value, and then what to do with the
>
other
>
values (set them to zero? ignore them? something else?). In
>
OtherPluginsToAU.rtf it says, "See below for plugin format specific
>
details," but those specific details are not found below or anywhere,
>
so
>
far as I can tell.
>
>
>
Also, about the "vstdata" ClassInfo key, in OtherPluginsToAU.rtf it
>
says:
>
>
"A valid aupreset dictionary is required to contain a number of
>
predefined
>
key-value pairs. In this case however, the dictionary that is given to
>
the
>
plugin need only contain one of these keys."
>
>
This, however, is contrary to what I've read before here on this list:
>
>
http://lists.apple.com/archives/coreaudio-api/2003/Feb/07/
>
crashesinaubaserestorest.003.txt
>
>
and (similarly) also to the implementation of AUBase::RestoreState(),
>
where only the "data" key is optional if using "vstdata", but
>
everything
>
usually required is still required if using "vstdata". So I'm
>
wondering,
>
which is correct?
>
>
>
thanks,
>
Marc
>
_______________________________________________
>
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
________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement [GSV]
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
_______________________________________________
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.