Re: question on refreshing parameter data between instances.
Re: question on refreshing parameter data between instances.
- Subject: Re: question on refreshing parameter data between instances.
- From: Darrin Cardani <email@hidden>
- Date: Thu, 13 Aug 2009 10:47:42 -0700
On Aug 13, 2009, at 10:17 AM, Brian Gardner wrote:
Thanks, Darrin.
It almost sounds like you're trying to change the value of one
parameter based on another parameter between when the user saved a
document and reopened it. Is that correct?
No, not at all. I'm just trying to save and recover the values that
the user set.
I'm using a singleton object (as you recommended to me a while ago)
as a way for the user to set global variables, that are common to all
instances of the plugin.
Since the singleton doesn't get serialized, itself, then I must
recreate the singleton, it's state,
and it's linkages to the plugins, during project open ... indirectly.
Ah, gotcha. That makes a lot more sense.
I have two challenges:
1. I complicated things by giving the plugin a "useGlobalValues"
toggle parameter.
It is the user's choice whether an instance of the plugin
functions independently,
(which the user rarely picks) or if the user wants it to be
ganged to the global values
(which is what they typically choose for this plugin).
So, whether the singleton is linked to this plugins' several
parameters or not
will depend on how the user set this "useGlobalValues" toggle
parameter.
When the user saves the project, and later reopens the project,
the state
of the plugins and the singleton need to match the way the user
had set it
from their previous project save.
The challenge is -- how do I save the singleton's state into the
project file?
And how do I recover that state, later, and re-instate the
linkages?
I think recovering the state should be fairly easy. In the case where
"useGlobalValues" is not checked, you don't need to even create the
singleton, so that case should work just fine already, right?
When the user does have "useGlobalValues" checked, you need to
actually create the singleton (if it doesn't already exist), and set
the singleton's values to those of your instance. So the host app
creates an instance of your filter and calls its -initWithAPIManager
method to initialize it, then calls its -addParameters method to
create the parameters. But at this point the parameters still don't
have the values that were saved with the document, they're just being
created with their default values. The host app will then internally
set the keyframes and values of all the parameters from the document.
That doesn't involve calling your plugin. So you probably won't get
any other messages until your plugin is asked to render the first time.
At that point, in -renderOutput:, your plugin will notice that it
doesn't have an instance of the singleton, so it will create it and
set its values to the values it currently has for its associated
parameters. You may have to have a method for creating the singleton
that looks something like this:
+ (SingletonClass*)createSingletonWithParam1:(int)param1
param2:(float)param2
... (whatever other parameters you have)...
{
if (globalSingleton == nil)
{
globalSingleton = [[SingletonClass alloc] initWithParam1:param1
param2:param2
...etc...];
}
return globalSingleton;
}
It's a little more cumbersome in that the method which returns the
singleton (and possibly creates it, too) has more parameters, so
calling it is less pretty. But that seems like a reasonable solution.
So what happens is the first time you call
+createSingletonWithParam1:param2:etc. it creates the singleton and
initializes it with the values you pass in for the parameters. The
next time you call it, the singleton already exists, so it ignores the
parameters that are passed in.
2. The plugin has its UI parameters, which (depending on the
"useGlobalValues" toggle)
should reflect either the local settings, or current global
settings .
When using global, this allows the user to see & change the
global value from any plugin instance.
So, I need to keep all of those parameters which are linked to
the global, in sync.
(Possibly, the singleton would need to update the UI parameter
for each plugin instance, whenever the global is updated.)
When a project is saved, whatever bookkeeping overhead and
mechanism is used to manage
these linkages, would need to be saved ... and recreated later
upon project open.
(But, the singleton does not get serialized / deserialized.)
This shouldn't be a problem in practice. When you first create the
singleton, it has the values of whichever instance of the plugin asked
for it to be created. The next plugin calls the create method, but
just gets back the existing instance, so it has the same values and is
in synch already. All instances that exist when the document is saved
should already be in synch. So when the document is reopened, they'll
still be in synch.
The plugin is mostly completed, and beta user feedback is very
positive.
But, I still need to solve the problems of how to save the user's
settings with the project,
and recover them later during the next project open.
You can also use the operating system mechanism for saving
preferences. See NSUserDefaults for the details. This has the
disadvantage that when you move the document to another machine, you
have to move the prefs file with it. But that might not be an issue
for your users – I don't know. It also means all instance of your
filter, regardless of project, use the same global settings. I don't
know if that's what you need or not.
Darrin
--
Darrin Cardani
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden