Announce your plugin work in progress here!!!!!!!! (2 Viewers)

[kaburke]

Input Mapper and LiveDriveIR Plugins

I've written two plugins: InputDeviceMapper and LiveDriveIR.

InputDeviceMapper accepts events passed to it by other plugins, maps them to Actions, and then passes those Actions on to MediaPortal for processing.

LiveDriveIR listens to the IR receiver on any LiveDriveIR (or Audigy Drive, etc.), and passes any events received to InputDeviceMapper. This plugin works by passing any System Exclusive (sysex) messages it receives on a given MIDI device on to InputDeviceMapper. For those who don't know, the LiveDriveIRs sends any signal their IR receivers pick up as Sysex messages on a MIDI device. The result is that this plugins turns the LiveDriveIR into a generic IR remote reciever. A receiver that, in conjunction with InputDeviceMapper, can control MediaPortal with any IR remote.

Why did I split this functionality into two plugins? The idea is that, now, any plugin can use InputDeviceMapper to map device events to MediaPortal Actions. A plugin that listens to the game port, for example, and passes any event it receives to InputDeviceMapper would allow one to control MediaPortal with gamepads/joysticks.

The mappings used by InputDeviceMapper are completely configurable, allowing any event to be mapped to any Action, at the user's dicrestion.

Both plugins work brilliantly for controlling MediaPortal; the only gremlin in their workings is in their interaction on the configuration side. Said problem will be detailed in a later thread (being written right after this post). I will edit in a link to said thread once it's started.

As promised, here is the thread.

The plugins have been uploaded as patches: InputDeviceMapper, LiveDriveIR

[EDIT]
Here are the threads that should be used for general discussion about these plugins: InputDeviceMapper, LiverDriveIR.
Technical discussions about the plugins, if they exist, are linked to from the above threads.
[/EDIT]

 

[mPod]

Re: Input Mapper and LiveDriveIR Plugins

I've written two plugins: InputDeviceMapper...

Where can we get this one? I have planned exactly the same, I think. A unified programming interface for "small" and easy to code remote plugins. And this seems to do exactly the job. It would be cool if you could provide the sources, as my already working (and most action-driven) Hauppauge plugin would surely benefit from your device mapper. If it's not really ready for public, you could have us a look at the sources. Sure my plugin works without your mapper, but it would be really cool to have a basis for all remote controls. No matter if they should be configured or not (learning, mapping, customization)... Did you get this idea on your own or did you follow the "discussion" on IRC?

 

[kaburke]

The plugins are ready, save the problem described.

You, or indeed anyone, can look at the sources, and/or give the binaries a try. The only obstacle is that I don't have anywhere to host the files. If someone could give me some space, or point me in the direction of some free space, then I would be glad to post my files.

Alternatively, I could e-mail the files to you (assuming some relatively private exchange of e-mail addresses is possible).

As to your last question, I came up with this on my own; I didn't realize there was an IRC "discussion." I downloaded MediaPortal a couple of days ago, and was dismayed that there was no support for my AudigyDriveIR, so I decided to write the plugins.

 

[ojo]

I you register yourself at SourceForge.net (hosts MP exe-files and CVS) you can upload the files as patches for starters.

Load the IRC channel and talk to fx. frodo to get the files added to CVS.

Then maybe talk to the admins (could be frodo, but not sure) and get them to add you to the team to get full r/w access to the CVS repository.

 

[mPod]

Then maybe talk to the admins (could be frodo, but not sure) and get them to add you to the team to get full r/w access to the CVS repository.

He does not need this. The devs are doing it, only a handful of people have rw access ot the CVS. If you made it into CVS, you can send the sources to Frodo. But talk to him if this is possible or if he wants to wait until the development has advanced. It's always dangerous to put "untested" code (meaning not beta-tested) into CVS, as its sometimes hard for "normal" users why a piece of software is not working the way he wants to be, cause it lacks of some kind of implementation. I think it's a good idea to let some people "alpha-test" the plugin before thinking about putting it into CVS.

But SF is a good place to post the plugins in the "patches" section. Please supply the sources as well, I'm so curious, what's under the hood. :wink:

 

[ojo]

Then maybe talk to the admins (could be frodo, but not sure) and get them to add you to the team to get full r/w access to the CVS repository.

He does not need this.

Hear hear !

The devs are doing it, only a handful of people have rw access ot the CVS. If you made it into CVS, you can send the sources to Frodo. But talk to him if this is possible or if he wants to wait until the development has advanced. It's always dangerous to put "untested" code (meaning not beta-tested) into CVS, as its sometimes hard for "normal" users why a piece of software is not working the way he wants to be, cause it lacks of some kind of implementation. I think it's a good idea to let some people "alpha-test" the plugin before thinking about putting it into CVS.

This actually points out a whole other discussion. This has to do with how you wan't to use your code-repository. I know it can be a problem to administer, but my experience tells me that code is stored in CVS (AT ALL TIMES) This not to insure integrety, but to insure the investment in work hours. Yes the freshly version in CVS would always be in an unsure state, but this the nature of the thing. Tagging, branching etc. is the way to ensure stabillity.

BTW isn't the coder's responsible for alpha testing?

Anyway, I'm not trying to start that religous discurssion.... so if you disagree please just disregard my remarks.

But SF is a good place to post the plugins in the "patches" section. Please supply the sources as well, I'm so curious, what's under the hood. :wink:

Exactly !

 

[mPod]

BTW isn't the coder's responsible for alpha testing?

Have you asked Microsoft about this? :twisted:

But this is not the correct thread for such discussions. It's an annoucement, not a discussion... :wink:

 

[kaburke]

InputDeviceMapper and LiveDriveIR Plugin Availability

The plugins have been uploaded as patches: InputDeviceMapper, LiveDriveIR

 

[kaburke]

New Versions of InputDeviceMapper of LiveDriveIR

Version 0.2 of InputDeviceMapper and version 0.2 of LiveDriveIR have now been uploaded.

InputDeviceMapper has had some serious work done to it. There have been some feature upgrades, a reworked plugin system, and some code clean up. See the changelog for more details.

The only change to LiveDriveIR was to make it compatible with the new InputDeviceMapper.

The plugins have been uploaded as patches: InputDeviceMapper, LiveDriveIR

If people have some spare time, I would appreciate feedback on these plugins (both their usefulness and how they're written). I will start a thread for such a discussion in the Plugins area and post a link here when it is created.

Here is the discussion thread.

 

[mbuzina]

Re: Input Mapper and LiveDriveIR Plugins

I've written two plugins: InputDeviceMapper and LiveDriveIR.

Thanks, this saved me a lot of coding and is defnitely more usable. I just finished first beta of my X10 RF Remote Control Plugin. In Germany the Medion RF Remote Control is bundled with PCs bought in the Aldi Stores (Supermarket, but good value for your money).

People interested may have a look at http://sourceforge.net/tracker/index.php?func=detail&aid=1181106&group_id=107397&atid=647927.