Re: Filing of User Presets
Re: Filing of User Presets
- Subject: Re: Filing of User Presets
- From: Bill Stewart <email@hidden>
- Date: Thu, 24 Oct 2002 11:20:02 -0700
I'm trying to keep up with this...
on 24/10/02 9:34 AM, Nikolaus Gerteis wrote:
>
Hello everybody,
>
>
FYI I just want to give you an overview how Logic does the preset
>
saving for Audio Units:
>
>
We get the class info which at least must contain a { CFSTR("data"),
>
CFData } pair where the CFData member should contain a full description
>
of the current plugin state. As the class info is a CFPropertyList, we
>
create the XML representation of it. Then we write this to disc.
I don't think this is a necessary restriction...
The AU publishes its internal state and whilst the default implementation in
AUBase will create a 'data' key even if this contains an empty value, I'm
not sure why you're requiring that this key be present.
In many ways the host shouldn9t care about the contents of the preset except
that that information has the keys we have defined for a host to be able to
find the correct audio unit and open it... However, once the host has done
that, it should be passing the class_info to the unit as it was originally
got from the unit. That said, having additional keys in there like a 'logic'
key is NOT a problem, because the AU will only care that the keys that it
knows about are there.
>
Currently a Logic specific header is written to the file as well, but
>
we think about removing this and replacing it with a { CFSTR("logic"),
>
CFData } pair in the property list, so the presets can be loaded by
>
other hosts as well.
>
>
We want to encourage the idea of storing such presets in a standard
>
location. In my personal opinion the solution
>
Library/Audio/Plug-Ins/Presets/Audio Units/Manufacturer/Plugin name
>
would be a good solution. Plus that the user can create subfolders in
>
there, to organize the presets.
>
>
On the compatibility issue: If a plugin exists as an Audio Unit and a
>
VST version, Logic provides the possibility to load the VST settings
>
into the Audio Unit, if the following conditions are met:
>
>
1. The Audio Unit sub ID is equal to the unique ID of the VST plugin
>
(four letter code).
>
2. The name of the Audio Unit is the same as the one of the VST plugin.
>
3. The Audio Unit can handle property lists that contain a pair {
>
CFSTR("data"), CFData } where the CFData member is a representation of
>
the data the VST plugin returns/gets in the getChunk/setChunk calls.
I don't like this either (as others have pointed out) - we are using a
'data' key already which contains the parameter values of an audio unit, and
we should tag vst derived data with a different key - 'vstdata' seems
reasonable to me..
Bill
>
Regards,
>
>
Nikolaus Gerteis
>
DSP technology and optimization
>
Emagic GmbH, Germany
>
_______________________________________________
>
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
__________________________________________________________________________
"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.