JP1 Remotes

[The Robman]

I think he's looking ahead to when these learned signals can be imported directly into RM, so he would want to delete the gap decodes first.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[gfb107]

The problem here is an apparent inconsistency in the syntax of the isTested attribute of learntremotekey elements in Sling Learned Signal XML files. In the "Sony" file linked above, I saw the following:

[eferz]

[gfb107]

Rob,

I've been thinking about how (Slingbox) users are going to create device upgrades based on learned signals loaded from XML files.

xnappo is experimenting with a sort of wizard to help the user pick a set of signals and build an upgrade. Another approach is to copy'n'paste information from the learned signal tab into the devices tab.

Either will require a second RM/RMIR instance running because we've defined the XMLLEARN RDF to have no upgrade memory, only learning memory.

Maybe it makes sense to add learning memory to the other Sling RDFs instead of using an XMLLEARN RDF. That way the same RDF can be used for the entire process of loading the XML learned signals, creating a device upgrade, exporting to BIN, and saving as an RMDU file.

The process would be slightly different, because first the user would do a File > New selecting the RDF that matches their Slingbox and then use File > Open to load the XML files.

Note that this would also allow loading XML learned signals into other remotes that support learned signals, although the key assignments would get scrambled because the keycodes wouldn't match. But if we use
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[The Robman]

I don't really have a major preference either way, regarding whether we should add learning to the Sling RDFs or add upgrades to the XML RDF, but if I were to lean in either direction, I think I'd rather add upgrades to the XML RDF as I think that makes it easier to make the process of importing XML files more universal. After all, like you suggested, it might be a regular remote user who's using the XML file to create an upgrade for his remote, rather than for a Slingbox.

As for the whole process of converting the learned signals into an upgrade, it would be ideal if that process were also universal because then people could use it for the signals that they learned using their remote, rather than a Slingbox.

Normally, creating an upgrade requires some user involvement because the protocol displayed for a single learned signal is not always the one that you would select in RM, I'm thinking of the various combo protocols of course.

If all the learns just happen to have the same protocol and device code(s), then the process could go ahead and make the right entries in RM, but otherwise I think the process should require the user to complete the Setup tab in RM first (ie, select a protocol and enter any device codes), then it should just copy over learned functions that meet the profile established in the Setup tab. For example, if the user selects "NEC 4DEV COMBO" as the protocol and enters 255.1, 256.2 and 257.3 as the device codes, then they try to import all of their learned signals, the only signals that should be imported are the ones which use the NEC protocol with a device code of 255.1, 256.2 or 257.3. In this case, the import process should not only populate the EFC/OBC columns, but also the Dev.Sub and Style columns.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[gfb107]

We'll see how xnappo does with the learned-signal-to-device-upgrade wizard.

At the moment I'm more concerned with how a user does this today (or the near future).

That process would be mostly copy-n-paste from the learned signal tab to a Device Upgrade Editor window. It really wouldn't matter if the signals got there by download from a remote or import from a Sling XML file.

I'm thinking the user would go the Devices tab, click the New button to start a Device Upgrade editor button (which would be non-modal so that's another change needed), or open an already installed device upgrade to which functions are to be added. The user would then switch back to the Learned Signals tab and go through the manual process of entering data in the Device Upgrade Editor's Setup tab. The user would choose the protocol from the drop-down list, but might be able to copy-n-paste all protocol parameters. Then the user would switch to the Device Upgrade Editor's Function tab, and copy'n'paste the functions.

I've enabled multi-cell selection and copy-to-clipboard in the learned signal tab to facilitate that, and I'm experimenting with a way for the user to flag decodes to be ignored for the duration of an editing session (or to flag one particular decode as the "correct" one to use), so that in some cases the user can turn ***Multiple*** decodes into a single decode for copy-n-paste purposes. I might enable column reordering to facilitate copy'n'paste as well.

I've built RMIR v2.00-preview3 with a bunch of changes related to learned signals and creating device ugrades from those signals.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[The Robman]

If RMIR is using the XML to display the learns, can the user still select a different remote when the RM editor is displayed? If so, I think what you're proposing is fine. If they can't, then we should add some upgrade memory to the XML RDF.

And yes, it would be a very good idea to let them sort the learns, if they can't do so already.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[eferz]

I hate to sound nick-picky, but would you consider only showing the "(untested)" flags for respective learns in the Notes column. I was playing around with a few xml files and realized that it was easy to overlook them if one was more prevalent than the other. I think it would be more pronounced if it only shows up for the ones which were flagged as untested.

For example, in the above screenshot, the "Left" and "Right" keys are untested but its easy to miss them.

[eferz]

Greg and Graham, I can't begin to express how grateful I am for all your time and effort into this request. It looks awesome! Thank you very much.

XML are easy to open, untested learns are more pronounced, and I can filter out multiple protocol matches. Pics for Proof!



Uploaded with ImageShack.us



Uploaded with ImageShack.us

[gfb107]

[eferz]

[mathdon]

[The Robman]

[eferz]

[The Robman]