More than one instance of Zoom Player - slightly erratic

[Ben S]

Avid - The new driver SDK that you're currently using has a "SetIsCurrent" "GetIsCurrent" on your plugin, and NetRemote controls having multiple instances.

And you can get the current instance of your plugin via:

NetRemoteDriver *current = this->GetLibrary()->GetCurrentInstance();

[avid]

Avid - The new driver SDK that you're currently using has a "SetIsCurrent" "GetIsCurrent" on your plugin, and NetRemote controls having multiple instances.

And you can get the current instance of your plugin via:

NetRemoteDriver *current = this->GetLibrary()->GetCurrentInstance();

Thanks - that should make it a bit easier this week - and better to enhance in the future.

Brian

[avid]

Mastiff,

I can't send an attachment via PM, so I have to post it here. This is a "work in progress" that might already be adequate for your needs, which should stop "leakage" from one instance to another. The ZP variables are only set or monitored for the "current, active" instance. However, there is (as yet) no action to set that instance - I am awaiting some clarification from Ben.

Let me know if it works for you.

Brian

[Ben S]

The "unified" way of doing this is now lua, though some plugins have specific code to do this.

To set a discrete instance:

plugin = NetRemote.GetPlugin('ZoomPlayer');
plugin_instance = plugin:GetInstance(instanceid);
plugin_instance:SetCurrent();

or, in one nice string:

NetRemote.GetPlugin('ZoomPlayer'):GetInstance(instanceid):SetCurrent();

note that GetInstance can use either the instance ID (as a number), or if the instance is "named" you can pass the name in.

Brian, you can have named instances by setting the variable "instance_name" in your instance.

[Mastiff]

Thanks, Avid! I'll try that out tomorrow. This day has gone into some hours of work (until around two o'clock) and then tidying up, vacuuming and washing the house. With that activity it should come as no surprise to anybody that my wife's coming home again today... Only need to shave off two weeks of laziness in the face and shower, and I'll be ready to receive the missus and the kids...and after about 15 minutes I'll find out wat I have forgotten on my day as a white tornado. There's always something. I never make the same mistake twice, but I'm very good at making new ones!

[Mastiff]

Yes, Avid! Thanks! That works just like you say, nothing funky happens on any of the Zoom Players when opening NetRemote. It only works on the first instance of Zoom that's set up even if the second instance is the only running, but you knew that, I suppose. If I delete the first instance it will start working on the second. Now I'm of course looking forward to being able to have both the kids' instances on the same NetRemote page, which will happen when you make it "new multi" aware. But never mind that for now. For now I would be very happy for a way to switch between the instances. Any chance of finishing off that this week?

[avid]

For now I would be very happy for a way to switch between the instances. Any chance of finishing off that this week?

I should be able to.

The risk is that I will rush the enhancements in a way that then turns out to be incompatible with Ben's preferred way of handling multiple instances in the future.

My current thinking is (as I understand is the case for Girder and MB) to have three new actions: SetCurrentInstance, NextInstance, PrevInstance. All the current actions will apply to the "current" instance instead of to the instance specified in the action code in the CCF.

Would that work for you?

@ben: Have I understood correctly the behavior of Girder and MB? When are you thinking of changing the encoding to have separate driver IDs and instance IDs, such that actions specified with the driver ID go to the "current" instance, but those using an instance ID go to that instance? And will CCFs break when this happens?

Brian

Brian

[Mastiff]

I can live with that. Of course I'd love to have adressable buttons that pauses a particular instance, but that can also be done through Girder. The Zoom driver's uniqe feature is of course the feedback. But would it be possible to set a specific instance instead of just going to the next instance?

[avid]

But would it be possible to set a specific instance instead of just going to the next instance?

Yes that is what the SetCurrentInstance action would do. The "current active" instance for feedback etc would be set to the instance specified on the SetCurrentInstance action.

Aside: I think this is analogous to what I used to do for MB before Ben added SetLibraryRoot().

@Ben: Am I thinking along the right lines, or is this going to break in the next version?? I want to "go with the flow" as how you see NR instance handling progressing.

Brian

[Ben S]

Again note that you can change instances -now- with the Lua code I pasted previously. The benefit of having them as actions is to expose them for NRD.

Brian - You're mostly correct. Next and Previous go against the -current- instance. The "SetCurrentInstance" should be used -directly- against an instance (IE: In NRD, open the "instances" folder, open the specific instance you want, and then use the SetCurrentInstance method there).

When are you thinking of changing the encoding to have separate driver IDs and instance IDs, such that actions specified with the driver ID go to the "current" instance, but those using an instance ID go to that instance? And will CCFs break when this happens?

This is already done in NetRemote 2.x. If you remove the ZoomPlayer instance and then create it again, you'll notice it gets an ID of -3014, you shouldn't (any longer) have an instance with the same ID as the plugin. This allows you to use the Plugin ID as the "default", and the distinct ID for a specific instance.

And this is handled internally, now. If an action is against the "default" instance NetRemote will figure out which one is current and execute against that one.