Re: Logic, AU development and parameter scrambling
Re: Logic, AU development and parameter scrambling
- Subject: Re: Logic, AU development and parameter scrambling
- From: Mark Pauley <email@hidden>
- Date: Fri, 28 Mar 2008 13:55:46 -0700
I absolutely understand that it's not up to logic to work this out in
the situation that I:
a) make a song and use my plugin and save the song
b) change the plugin's param layout
c) open the song again.
I'm fine with that... there's no possible way Logic could work with
that mess.
However I feel like this should work:
a) make a song and use my plugin and save the song
b) change the param layout
c) open the song (params are scrambled)
d) change the param settings and save the song
e) re-open the song
Here's what actually happened, I _strongly_ feel like this should work:
a) make a song and use my plugin and save the song
b) change the param layout
c) open a _new_ song and use my plugin and save the song
d) re-open the song
This seems like it would clearly point to some sort of application-
wide (or possibly even system-wide) caching of parameter data... be
that parameter type information or index information or whatever.
Since I see my plugin's new parameters and the settings I give them
are obviously having the correct effect before I save / reopen, to
save the info and re-open in a scrambled state is at the least
inconsistent behavior.
Nobody's using my plugin but little old me... and I'm fine with having
to re-create my param settings if I want to change stuff, the songs
are sandboxes of the plugin anyhow... I am just wondering if there's
something more I can do than "reset and rescan" my plugin that will
allow a song to at least persist settings across a save.
_Mark
On Mar 28, 2008, at 1:40 PM, Brian Willoughby wrote:
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