Re: Logic, AU development and parameter scrambling
Re: Logic, AU development and parameter scrambling
- Subject: Re: Logic, AU development and parameter scrambling
- From: Brian Willoughby <email@hidden>
- Date: Fri, 28 Mar 2008 13:40:03 -0700
On Mar 28, 2008, at 13:02, Mark Pauley wrote:
I am fooling around with AU effect plugin development and I've got
the following issue: I am incrementally developing an audio unit
effect with no UI, and I've switched the parameters around a bit
(they're different ID's than when I started as well as listed in a
different order).
Every time I save a song in Logic with my plugin and re-open the
song later all instances of my plugin have scrambled parameters...
I realize that I'm not supposed to monkey with the param ID's like
this, but I'm just doing development right now. If this is a
caching problem, is there something I can do to erase Logic's
memory? Do I have to bump the version number or is there something
easier I can do?
It's not a caching problem, it's operator (or developer) error. :-)
When you save a song, the saved file *is* the cache. It stores the
param IDs of the plugin version that was part of the song when you
saved it. If you load that song later, with a newly scrambled
plugin, then the parameters will be scrambled. The param IDs only
live in two places: Your plugin, and the saved song. If you change
one, then the other will be scrambled next time they're matched up by
Logic.
The only possible way you can expect to change your parameters to new
IDs and have Logic match them up with the old parameters is if you
write the necessary translation code into your plugin. Think about
it: How is Logic supposed to know how to load your old songs, made
with the old plugin versions, and map the parameters to the new
ones? There is no AI in Logic that would try to match up differing
IDs, and if there was, I'm sure it would not always work. This sort
of thing does not happen to normal users.
The only way around this is for you to do extra work, otherwise
you're going to be stuck with the mixed up params.
The easiest solution is to not change IDs for existing parameters.
I'm sure you've thought of this, but prefer to have a sensible order
for parameters - especially with no custom UI. My free plugins do
not have UI, so I understand.
The only other solution is to carefully change your plugin version
number every time you scramble the param IDs, and implement custom
SaveState() and RestoreState(). In RestoreState(), you should be
able to look for old version numbers, and have a special section of
code for each old version that you want to support, where your code
translates the old param IDs to their current matching IDs (and you
can also supply reasonably compatible value for the new parameters
which did not exist in the old versions). If you detect the current
version, you can simply do nothing, and the standard implementation
of RestoreState() should handle the simple case. This is a lot of
work when you're supporting a user base of only one (you), but this
would be mandatory for a commercial plugin which had multiple version
releases, with even one changed param ID between them.
It seems like you shouldn't have to do anything special in SaveState
(), but I noticed that there is a kCurrentSavedStateVersion which is
set to 0 in AUBase.cpp, and you'd have to find a way to override
this. I don't think that the code is set up to make this easy.
You'd have to completely duplicate the code in SaveState() and not
call your superclass, because there's no way to provide a different
state version for each plugin that necessarily inherits from AUBase
(directly or indirectly). Perhaps I misunderstand the purpose of
kCurrentSavedStateVersion, but this seems like something which needs
to be addressed in the CoreAudio SDK. It seems odd that SaveState()
doesn't call GetComponentVersion(GetComponentInstance()) instead of
hard-coding this to 0. I may have to bugreport it unless someone
convinces me otherwise.
To get back to your situation, I suggest that you do one of the
following:
1) Don't save songs in Logic containing plugins that you are
developing and plan on changing params.
2) If you do have saved songs, then maintain the parameters IDs or be
prepared to lose existing songs.
3) Maintain the order of existing parameters during your development
stage, and only reorder them when you make a final release to the
public (keeping in mind the the first two caveats when you do)
4) Implement SaveState() and RestoreState() to translate, and each
time you save songs with a given version number, you'll have to
modify the State if you modify existing param IDs.
I realize that the last option is a lot of work, but it's your only
option other than losing old song data that was saved with old plugins.
Brian Willoughby
Sound Consulting
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden