RemoteMaster v0.90 now available!

gfb107 · Post by **gfb107** » Fri Feb 20, 2004 8:45 am

I've built and released RemoteMaster v0.90

Changed for v0.90

- Add DigitMap entires up to 170
- Update images and maps to v1.14
- Add most support for Device Combiner. Importing a KM file that uses Device Combiner is not yet supported

Links:
RemoteMaster.v0.90.zip
Release Notes and Change Log (also included in the ZIP file)
Installation Instructions (also in the Readme.html included in the ZIP file)
The RemoteMaster project home page.

johnsfine · Post by **johnsfine** » Fri Feb 20, 2004 9:07 am

I tried to get the source code from SourceForge and compile it and DeviceCombinerInitializer came up undefined.

I'll check later in case I did something wrong, but first guess is you forgot to add a file to SourceForge.

(Of course this problem only affects developers not users of RM).

gfb107 · Post by **gfb107** » Fri Feb 20, 2004 9:07 am

I suppose some instructions for the new Device Combiner support is appropriate.

When the "Device Combiner" protocol is selected on the Setup panel,
a new "Device Combiner" panel appears.

The "Device Combiner" panel allows you to Import a device from an existing RM or KM device upgrade file. The "Remove" button doesn't work yet.

Before importing your first upgrade, it is a good idea to delete all the predefined functions. I may automatically do this in the future.

When you import a device upgrade file, you may be prompted to select a remote for the imported upgrade. This is not the remote for the upgrade you are creating, but for the upgrade you are importing, so choose appropriately.

Next, RM will check to make sure that the imported upgrade uses 1-byte commands. If not, you'll get an error message.

Next you will be prompted to select the functions you want to import from the upgrade. Once you have done that, the functions will be available on the Functions panel, at the bottom of the list (which is why I recommend deleting the predefined functions). There is no checking for duplicate function names, that is up to the user.

Assigning functions to buttons is done on the Buttons or Layout panels as always.

gfb107 · Post by **gfb107** » Fri Feb 20, 2004 9:11 am

Warning!

I just noticed that when a device upgrade is imported, the functions in that upgrade are automatically assigned to the buttons, which is wrong. Not only that, but even functions that haven't been imported are assigned.

As I said above, the Device Combiner support is not complete.

gfb107 · Post by **gfb107** » Fri Feb 20, 2004 9:12 am

johnsfine wrote:I tried to get the source code from SourceForge and compile it and DeviceCombinerInitializer came up undefined.

I'll check later in case I did something wrong, but first guess is you forgot to add a file to SourceForge.

(Of course this problem only affects developers not users of RM).

Sorry about that. Its there now.

Nils_Ekberg · Post by **Nils_Ekberg** » Fri Feb 20, 2004 9:46 am

Greg

Nice job.... I like concept where you can choose an existing upgrade and not have to enter anything other than selecting the import buttons and changing the duration.

On the duration I would suggest making the default something other than 0. John may be able to suggest a good starting point like maybe 2 or 3 since that seems to work for most DC upgrades.

I am not sure only importing limits people but it may for people who just create DC for one or two buttons for a a device already existing in the remote. eg. they did not have an upgrade to start with.

And yes, you were 100% correct about it not generating the correct protocol but I know you really don't need that feedback.

Outside of it accidently importing everything and posting it on the buttons and layout panel there was only one problem I noticed and that is that the "remove" does not work. Doing a new in the file menu does make the tab go away but if you select DC again the prior one is still there when the panel comes back. Ofcouse closing RM does clear it unless you save it.

Mark Pierson · Post by **Mark Pierson** » Fri Feb 20, 2004 10:20 am

Nils_Ekberg wrote:On the duration I would suggest making the default something other than 0.

I would say leave the default 0 (which I believe uses the protocol default), and let people who need duration tweak the setting to their individual needs.

Nils_Ekberg · Post by **Nils_Ekberg** » Sat Feb 21, 2004 8:48 am

Mark Pierson wrote:
Nils_Ekberg wrote:On the duration I would suggest making the default something other than 0.
I would say leave the default 0 (which I believe uses the protocol default), and let people who need duration tweak the setting to their individual needs.

Thats fine by me. The only reason I suggested it was because many people who use DC are using it to increase the duration. However, as I think about it the default of 0 is good for people who are actually using it to define multiple protocols.

Mark Pierson · Post by **Mark Pierson** » Sat Feb 21, 2004 1:54 pm

Nils_Ekberg wrote:many people who use DC are using it to increase the duration

It's time for somebody to write a generic duration protocol.

streetskater · Post by **streetskater** » Mon Feb 23, 2004 10:48 pm

Interesting,
I'm actually tracking down some rdf problems with IR & the 15-1995 that crept in (well in my archives--somewhere after IR 3.22), KM & RM are giving me correct fixed data whereas IR is wanting to use a whole big chunk of the beginning of certain upgrades as fixed data when most of it is actually device mapping. Obviously that creates cascading errors.

I thought the problem was with IR but when I substitute the older 1995 RDF's in my IR 4.02 directory, everyone's happy again.

I wonder if I'm the only person still plugging away with the 1995's--. I still really like it although the new 2117's I just got are probably going to turn them into paper weights. Actually my Palm Pilot with OmniRemote is the most powerful remote control device I have but I would never give up old fashion button remotes for touch screens.

Anyway RM is serving as a kind of sanity check. It's not perfect yet but it's fun to play with and it's doing some real work for me--The graphic display of the actual remote is very useful especially when trying to duplicate functionality between remotes with similar but not identical layouts.

I'm still having some problems with Device Combiner protocols but definitely a step forward from .89