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: Steve Christensen <email@hidden>
- Date: Thu, 13 Aug 2009 14:31:15 -0700
On Aug 13, 2009, at 12:38 PM, Brian Gardner wrote:
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.
You are correct up to this stage.
There is no issue until the user decides to alter a global value by
changing a parameter value.
That parameter change will in turn update the corresponding global
value, stored in the singleton.
At this point, all of the other plugin instances set to
useGlobalValues will have a parameter value that still is set to
the old global value, except the one that the user has just
changed. So, the change must be rippled to all of the other
instances of the plugin.
Normally, I'd expect to do this by having the singleton maintain an
array to keep track of the relevant plugin instance id's. Toggling
an instance's useGlobalValues parameter, would add/remove it from
the singleton's array. The singleton could loop through this array,
to send a message to each managed plugin instance to perform a
setParameter, to reflect whenever a global value changed.
This makes the assumption that a plugin instance is created for each
clip that uses your effect and that the instance will hang around in
memory until either that clip is removed, the project is closed or
the host app quits. I don't know the underlying architecture but it's
just as likely that plugin instances are created as needed and then
destroyed if you're not currently working with a particular clip.
If you create an array and add instances to it, you -could- end up
with a bunch of stale items that no longer refer to real clips and/or
conflict with the plugin instance that now manages your effect for a
particular clip.
But... just after an 'open project', the id's are not the same as
in the previous session (I think), and the singleton has an empty
array anyway (singleton data wasn't seralized). So, this array
would need to be reconstructed somehow after the 'project open'.
Since the deserialization of the useGlobalValues parameter bypasses
ParameterChanged, it never invokes the singleton. So the singleton
can't build a list of the relevant plugin instance's new id's.
Perhaps, I can replace the toggle with a 'custom parameter' toggle,
just so that i can trap the deserialization? Then I could (re)build
a new array upon project open.
Again, this assumes that effect instances will be created for all
clips when the project is opened, and furthermore de-serialization
also occurs for each of those instances. That may be the case for the
few clips visible in the timeline, but what happens if you have, say,
50 or 100 clips with your effect applied?
You can also use the operating system mechanism for saving
preferences. See NSUserDefaults for the details. ...
... 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.
Definitely would be an issue -- not what the user wants in this
particular case.
Actually, the user wants these globals to be scoped to the
sequence. Almost like a Sequence Setting (but with easier access,
since the globals are changed more often).
Unfortunately, I can't figure out how to do that. So, the best I
can do is using a singleton ... which is probably Project scoped,
which is acceptable.
Though, if the user can open multiple projects in one session, then
it's probably not even project scoped, it's probably session
scoped. (Session scoped is also not very desirable, either.)
Plugins are called to perform their effect on some arbitrary clip,
thus their scope is the host application, not an individual project
or sequence. In other words you can't really tell which project-
>sequence->clip is associated with a particular plugin instance.
Certainly, somehow, these global settings must be scoped and stored
within the Project file.
Generally the only plugin-specific data is that which is serialized
on a per-clip basis. I have not seen a "global settings" area within
a project that can be associated with a particular plugin (vs
instance). Thus Darrin's suggestion about using NSUserDefaults makes
more sense as a repository for your global settings. Unless your user
is going to be moving project(s) from machine to machine,
NSUserDefaults is a non-issue. It also gets rid of the hoops you're
jumping through to try to manage settings across multiple plugin
instances.
steve
_______________________________________________
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