InputDeviceMapper and LiveDriveIR Configuration Problem (1 Viewer)

[kaburke]

The devices I will be discussing are detailed here.

Before I begin, it should be noted that the LiveDriveIR plugin allows you to select the MIDI IN device to listen to in order to receive the remote control events.

The problem I'm encountering occurs with a feature built into InputDeviceMapper's configuration. The setup form allows you to "learn" new events to be mapped to Actions. Basically, you click the "Lean Command" button on the form, a window pops up telling you InputDeviceMapper is waiting for input, and then you push a button on your remote (or gamepad or whatever - in this case it is a remote). The captured event is then used to create a mapping. This is accomplished in the following manner:

When the InputDeviceMapper setup form starts, it uses the PluginManager to get a list of all of the plugins. InputDeviceMapper loops through that list looking for plugins that implement the IInputDevicePlugin interface. When one is found (in this case LiveDriveIR), InputDeviceMapper calls it's start() method to ensure that it is listening for events that it will pass to InputDeviceMapper. Once the command is learned, InputDeviceMapper goes through the list again, calling stop() where appropriate to return the plugins (again, LiveDriveIR in this case) to their original state.

This works fine, unless the plugins' (LiveDriveIR's) configuration is changed. Consider the following scenario:

I go into InputDeviceMapper and try to learn a new command. Nothing is happening. I decide that I need to change the selected MIDI IN device in LiveDriveIR, so I close the InputDeviceMapper configuration form, and open LiveDriveIR's. I select the correct MIDI IN device and close the form. I open InputDeviceMapper's setup form again. It uses the PluginManager to get/instantiate the required plugins (LiveDriveIR).

Now, those of you who are observant, and know the Configuration application, will see what's comming. As it turns out, the changes I made to the LiveDriveIR's settings have not yet been written (that's not done until the Configuration Application closes), so when PluginManager instantiates the plugin, it is instantiated with the OLD settings. The upshot is that no matter what I set my device to in the LiveDriveIR setup form, InputDeviceMapper won't benefit from the change until the Configuration application is restarted.

The solution, of course, would be to get the instance of LiveDriveIR that already exists in the Configuration application, rather than using PluginManager to recreate it. Unfortunately, I can't firgure out how to do that. Indeed, I'm not sure it is even possible.

Any suggestions?

 

[Anonymous]

i don't no if I got the point, but what about using one static instance for each IR? Look at mediaportal\Core\SerialUIR which uses just one instance for handling a serialUIR

P.S. interesting concept your InputDeviceMapper - I wrote recently a WinLirc addon, if your idea works fine I could try to code it using your interface...

[EDIT]
another question, what about making an own specialized IR-Plugin concept/interface so that IR-Plugins are not directly shown in MP-Configuration but only made accessible and configurable in your InputDeviceEventMapper-Plugin? - I think it would be clearer arranged and you could make the new interface better fitting to the need of IR-Plugins...
[/EDIT]

keans

 

[kaburke]

In answer to your first question (static pointer), that would be nice, but the application instantiates the other plugins (e.g., LiveDriveIR, etc.) independantly of InputDeviceMapper, so how would I get a handle to it to store it in the first place?

Having said that, your second question is quite interesting, and negates the first (sort of). The idea of making the plugins separate from the built-in plugin system strikes me as a good one. Indeed, short of anyone pointing out any reasons why that would be a bad idea, I am going to go ahead and implement it.

One final note, not to be nitpicky, but I don't want the InputDeviceMapper to be restricted by misconceptions: the device plugins (e.g., LiveDriveIR, etc.) need not be IR plugins. They could be gameport plugins, keyboard plugins, etc.

(I apologize if you understood that already - as I said, I just don't want others getting the wrong impression, and thereby limit the potential usefulness of InputDeviceMapper.)

 

[Anonymous]

I thought that if for example LinDriveIR is a "normal" plugin it has a start() method and so could be made static while configuration is loading, but I see that is perhaps a contridiction to dynamic loading... - so better forget about it :roll:

I prefer the second idea - I think it would be more flexible and sure I got that your InputDeviceMapper can handle different types of controls ;-)

I don't see any negative aspects at the moment - I think it will be an offer for easy control handling and there will be no duty to use it - if you don't want to...

keans