Re: AudioUnitPropertyMigrate question
Re: AudioUnitPropertyMigrate question
- Subject: Re: AudioUnitPropertyMigrate question
- From: Marc Poirier <email@hidden>
- Date: Mon, 14 Jun 2004 16:29:09 -0400 (EDT)
I do realize that we're not talking about aupreset files here. It's about
the situation where a document was saved with a Mac OS 9 app with VST
plugin sessions as part of the document, and then you open that old
document in the Mac OS X version of that app and the app loads the AU
version of that plugin and tries to give the VST version state data to the
AU for the AU to hopefully restore state from that VST data. So, I know I
wasn't so clear in my first message and I apologize, this time I hope to
be more clear.
So anyway, the thing is that, the message in the archives from many months
back that I referenced, that was when Logic was first adding support for
giving "vstdata" to AUs, and I wrote because my plugin would crash because
there was a "vstdata" key and nothing else in the ClassInfo dictionary.
My implementation of RestoreState() would (and still does) start by
calling AUBase::RestoreState() and then, if that succeeds, continue on to
process any private data and/or "vstdata" in the dictionary. So
AUBase::RestoreState() was crashing when the required keys were missing.
Your response at the time was "this is an illegal format - some keys in an
AU Preset are required," and so Logic changed to still give all of the
required keys with the "vstdata".
I may be confused or missing something, but I really think that this does
contradict the latest docs. But if the latest docs are the latest and
final word on it, then that's what I'll go by (though unfortunately it
does mean that all of my AUs with VST counterparts currently do not work
correctly, because they are designed to reject "vstdata"-only
dictionaries).
The AUBase::RestoreState() implementation also does have some handling of
"vstdata" and would I think lead one to believe that "vstdata" still
requires the other keys, except for "data". The current handling is that
all of the other required keys are checked, if they fail, RestoreState()
fails, and then it checks for "data", restores it if it exists or
otherwise checks for "vstdata" if "data" does not exist, and if one of
those exists, there is no error. Though of course AUBase::RestoreState()
doesn't do anything more with the "vstdata" beyond that. But this, I
thought, was done so that I can do exactly what all of my AUs currently
do, which is to verify the dictionary and restore the required stuff using
AUBase::RestoreState(), and then if that checks out okay, do my custom
stuff.
So I guess I just want to make sure that I'm being clear and understood
about this all, and then here a "ignore that old stuff and just listen to
the latest docs", or "woops, ignore the latest docs", or "Marc, you are
totally confused and here is why..." to confirm what I should do.
Aside from this stuff, I don't want to distract from my first question
from my original email, which was about the AudioUnitOtherPluginDesc stuff
for VST, which I think was forgotten, but I'm still completely unsure how
to work with that and would love an answer! :)
thanks,
Marc
On Mon, 14 Jun 2004, William Stewart wrote:
>
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.
_______________________________________________
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.