JP1 Remotes

vickyg2003 wrote:

Capn Trips wrote:By the way, is anybody actually using the feature request and bug report features at sourceforge to document all of these ideas? I try to do the ones I identify, but I seem to be the only one.

Have no idea where it is, nor how to use it.

Try the link.

Capn Trips wrote:Try the link.

Can't find any place to submit a ticket. Obviously you must have a login, but can't find anyplace to get one of those either.

vickyg2003 wrote:Can't find any place to submit a ticket. Obviously you must have a login, but can't find anyplace to get one of those either.

You can log in to Sourceforge with many other accounts (google, yahoo, flickr)...

https://sourceforge.net/account/login.php
Click the service you want to log in with

Then click here for the bug/feature request tracker:
https://sourceforge.net/tracker/?group_ ... tid=399669

xnappo

The Robman wrote:I see the Denon-K upgrade was made using RM, is that why Denon-K was picked over Panasonic, or is RMIR using the fixed data to distinguish them?

RMIR is using the device parameters that are encoded into the fixed data. If there are two or more otherwise identical protocols in protocols.ini that have different default values for device parameters whose names start with "OEM" then it picks the one where the actual values of these parameters are closest (sum of the absolute value of the differences) to the default values. I did say that it is using only the data in the remote's binary image.

That sounds great. Any reason to limit it to OEM codes though? I would think that any fixed data code that has a default value could benefit from the same logic, as there are other executors that serve multiple protocols.

mdavej wrote:... just to throw another huge monkey wrench into the works, I'm thinking of a totally different paradigm. I think when you open RMIR, the first thing you should see is a picture of the remote (the is one of the best things about RM), like the layout tab in RM. Then click a device button (or phantom device button) to assign a setup code or macro. Those details could show on the right like the general tab does today. The other stuff on the general tab (VPT, etc.) could be managed there too. Clicking buttons other than device buttons would let you manage macros, keymoves or learns associated with that button or the whole device upgrade for the active device mode. The other tabs we're used to seeing in IR are great summary views and should be accessible in one form or another, but the bulk of remote management should be accessed from that first graphical page.

A few more specifics on this home/main page I'm talking about. If you click a device button, that sets the active device. If you click any other button, it shows the layout tab in RM for that device upgrade with the button you clicked highlighted. If the button is associated with a device other than the active device, you're given the option to manage keymoves or macros (or learns or special protocols).

RMIR: The Next Generation?

Perhaps highlighting just the Device buttons on this screen (and/or the Setup button). Single-click to assign a Setup Code, double-click shifts to the Devices Tab with that device opened in RM in the side panel, etc.

Lots to consider in terms of the actual GUI.

RMIR v.3.00?

The Robman wrote:That sounds great. Any reason to limit it to OEM codes though? I would think that any fixed data code that has a default value could benefit from the same logic, as there are other executors that serve multiple protocols.

There is a reason to limit it to device parameters that are related to protocol selection, but not necessarily just to OEM ones. Consider a simple but fictitious example: a protocol executor with device parameters Device and OEM, used by two different manufacturers who use their own particular OEM values: OEM=8 for Protocol-X, OEM = 12 for Protocol-Y. Protocol-X commonly uses Device=16 while Protocol-Y commonly uses Device=0, but both do use other values in range 0 to 31. So the defaults are set as:

Protocol-X: Device=16, OEM=8.
Protocol-Y: Device=0, OEM=12

We create an upgrade for Protocol-X with Device=4 instead of 16. Then the variance from the default is (16 - 4) + (8 - 8) = 12. But considered as an example of Protocol-Y the variance is (4 - 0) + (12 - 8) = 8, which is smaller and so it would be picked as now being Protocol-Y. The change of value for Device, which should not affect the protocol, has overridden the difference between the OEM values for the two remotes.

I have now looked at a fair selection of protocols in protocols.ini where the same executor is used for protocols with different names. RMIR already uses the number of fixed bytes as a selection criterion, so it is only when both the executor code and the number of fixed bytes are the same that there is an issue. There are more cases of this than I expected. In some cases the same number of fixed bytes even translates into device parameters that differ in both number and name. However, restricting the variance check to device parameters whose name begins with either "OEM" or "Parm" - the latter dealing with the NEC variants - seems to work pretty well and can be made even better by minor additions to certain of the protocols concerned. "OEM" seems suitable for protocols from different manufacturers, "Parm" for different protocols from the same manufacturer.

How does this seem?

Capn Trips wrote:
Lots to consider in terms of the actual GUI.

RMIR v.3.00?

Perhaps this can be combined with Elizabeth's idea. When you click on a device, the bottom could become a device summary showing what every key is programmed to (highest priority - upgrade,keymove, learned, macro, special function). Clicking a key on the image would jump to the row in the summary. A button next to the programmed function could jump to the appropriate tab where the upgrade/keymove/macro/learned signal comes from.

xnappo

xnappo wrote:

Capn Trips wrote:
Lots to consider in terms of the actual GUI.

RMIR v.3.00?

Perhaps this can be combined with Elizabeth's idea. When you click on a device, the bottom could become a device summary showing what every key is programmed to (highest priority - upgrade,keymove, learned, macro, special function). Clicking a key on the image would jump to the row in the summary. A button next to the programmed function could jump to the appropriate tab where the upgrade/keymove/macro/learned signal comes from.

xnappo

By "bottom" I presume you mean the current "General Notes" area? I like it!

vickyg2003 wrote:

vickyg2003 wrote: Another Bug
If I edit the device and change the type/device number, I don't get the "do you want to associate the device with a device button message, even if there are keymoves". I don't know if it properly changes the keymoves since I can't see them. But oh well what does that matter!

Its a bigger bug than I thought. Editing the device type and device number, doesn't actually effect the device. RMIR says I have TV/0001 but the upgrade is actually DVD/1227 and all of the reported keymoves don't exist.

I think I've dealt with all this, but it isn't in a released or preview version yet. It is even worse that you think, even now! In the version you have (the latest so far, and any earlier ones) the "OK" and "Cancel" buttons have the same effect, which is right for neither of them!

Looks like I'll finally have a little time for this again tomorrow morning.

The first order of business will be to build and upload a preview release with the fixes and enhancements Graham has made. Then I'll work my way through the many pages of posts I've missed this week.

We may have forgotten, but there is a separate Sticky Thread for Feature Requests that had previously been used - and Greg would populate those requests to the SourceForge Feature Request tracker for those who could/would not do so directly. Not sure where the dividing line is, but a lot of the discussion in this thread are probably better suited for that other thread.

RM/RMIR v2.00-preview4 is available for download.

vickyg2003 wrote:I haven't read back to the point where this was introduced

This was a feature of RMIR right from the start.

Please keep in mind that RM is the core of RMIR. RMIR was built around RM. This has resulted in the (overly?) device-upgrade-centric nature of RMIR.

RM (and KM for that matter) is really about managing the known functions for controlling a device, and assigning those functions to buttons. Some of those assignments are stored in the remote as a device upgrade. Others are stored in the remote as keymoves.

Parsing an IR file started with the goal of recreating all installed device upgrades. Later support was added for general settings, macros, "non-upgrade" keymoves, special functions, learned signals, etc. But the core focus on recreating the installed device upgrades remains.

For those interested in implementation details, I would like to point out a fundamental difference in the design of IR and RMIR.

IR is based entirely on a copy of the remotes EEPROM. The UI displays and manipulates the bits and bytes in the EEPROM image directly.

RMIR is based around collections of logical object that are representations of the things allowed in our remotes. The copy of the remote's EEPROM is only used when

1. Parsing an IR file or download from a remote into the collections of logical object
2. Uploading to the remote
3. Viewing the RAW Data tab

The UI displays and manipulates the collections of objects, not the EEPROM image.

When the EEPROM image is needed (for upload or viewing the Raw Data), RMIR completely regenerates the appropriate portions of the EEPROM image from the collections of objects

vickyg2003 wrote:So how do you keep your device upgrades centralized? Everytime you edit your RM file do you need to have two RM sessions open that look exactly alike, one that's holding what's in RMIR, and the other with your master RM file? If so, how do you keep track of whichi is which? OR do you abandon the RM master file for each piece of equipment you own?

Anytime you edit an installed device upgrade in RMIR, you can Save that device upgrade to a an RMDU file (probably replacing your master file).
You may then open your other RMIR files and load this updated master rmdu file in place of the installed upgrade, and check the button assignments. (The handling of existing assignments and addition of new assignments needs testing, especially when using different remote models).

Another possibility is to make the change in the master RMDU file, then open each of your RMIR files, edit the installed upgrade and load the master RMDU in it's place and check the button assignments.

A third possibility is to forget about the master RMDU file altogether and simply copy'n'paste the changes to all your RMIR files.