RMIR: Prototype IR function in RM

[mathdon]

The problem is that the upgrade doesn't overflow in IR, RMIR is counting the memory differently.

No, it wasn't counting memory differently, it was a bug. The bug caused spurious buttons to be mapped in two of the upgrades. If you check you will see, for example, that in upgrade SAT/CBL 0135 the keys Move and Swap are not mapped if viewed in IR.exe but are mapped if viewed in RMIR.

I have corrected this. It now shows 18 bytes free in the upgrade area, as does IR.exe. The correction will be in the next release.

[mathdon]

I have added to RMIR a facility to import protocols from ProtocolBuilder and to be able to edit them either before or after they have been used in a device upgrade. This works as follows:

• * Open the Protocols tab. It will probably be empty, as in RMIR this tab shows only protocols that are not used in any device upgrade.
  
  * The "New" button on this tab now works (previously it was enabled but did nothing). It opens the Manual Settings dialog, as available through the Advanced menu of RM. With it, protocols can be imported from ProtocolBuilder exactly as with this dialog in RM.
  
  * Once imported, they appear on the Protocols tab and can be edited by double-clicking or by the Edit button, both of which again open the Manual Settings dialog but showing the selected protocol.
  
  * To use the import in a new device upgrade, go to the Devices tab and press New. The usual Device Upgrade Editor dialog opens but you will now find the imported protocol in the drop-down list. If you have given it PID=01FF then it will be at the bottom of the drop-down list, named "Manual Settings: 01 FF.
  
  * After you use the imported protocol in a device upgrade, it will no longer appear on the Protocols tab (as it is now used by a device upgrade). However, it can now be edited from the Devices tab. It, and any other protocols listed as Manual Settings in the "Protocol" column, can be edited by double-clicking the protocol name in that column. This again opens the Manual Settings dialog, showing the protocol concerned. Note that it must be that column, as double-clicking in any other column will open the Device Upgrade Editor.

This new facility will be in the next release.

[The Robman]

That may well be where we end up. But you all seem to be under the impression that showing all keymoves on the keymoves tab, and all protocols on the protocols tab is something we could do in just a few hours of work. That is not the case. It is a BIG job. That's why it hasn't been done yet. It would take a lot of work to keep those three tabs in sync with each other as changes as made in each of those tabs, and to keep the user informed of things that shouldn't be done or that might have unintended consequences.

I'll take your word for it that it's a big job, but I don't see why it should be so. Assuming that you're basing all the displayed info on what's actually in the E2 image, it shouldn't matter whether the user updates the keymove via the Keymoves tab or any other tab where you might have the info displayed, because as long as you're writing the updates back to the E2 image, the display in the other tabs should be updated automatically.

[xnappo]

That may well be where we end up. But you all seem to be under the impression that showing all keymoves on the keymoves tab, and all protocols on the protocols tab is something we could do in just a few hours of work. That is not the case. It is a BIG job. That's why it hasn't been done yet. It would take a lot of work to keep those three tabs in sync with each other as changes as made in each of those tabs, and to keep the user informed of things that shouldn't be done or that might have unintended consequences.

I'll take your word for it that it's a big job, but I don't see why it should be so. Assuming that you're basing all the displayed info on what's actually in the E2 image, it shouldn't matter whether the user updates the keymove via the Keymoves tab or any other tab where you might have the info displayed, because as long as you're writing the updates back to the E2 image, the display in the other tabs should be updated automatically.

Actually Greg explained earlier that that is exactly NOT what RM-IR does. RM-IR does not directly manipulate the EE image. It has a collection of objects that are maintained separately and when an EE image is needed, it regenerates it on-the-fly. All of the information displayed is from the data structure, not the EE image.

That said - an implementation like the one Capn suggest... I think may not be as hard if:

1. When the keymove is part of an upgrade, it is displayed as greyed-out. This indicates it comes from a key move and should be edited in the upgrade. This should be just displaying the keymove portion of the 'RM' output.
2. The ability to dis-associate the upgrades. Slightly more complicated, but basically copying the data structure from the upgrade into the 'global' keymoves and then deleting from the upgrade.

That said, we only have a certain amount of developer bandwidth - and if this is just a temporary solution with the full solution being a 'summary' output that shows what is bound to every key including much more than just keymoves (macros, learns, special functions) then time may be better spent rounding out that idea and implementing it.

xnappo

[Capn Trips]

That said - an implementation like the one Capn suggest... I think may not be as hard if:

1. When the keymove is part of an upgrade, it is displayed as greyed-out. This indicates it comes from a key move and should be edited in the upgrade. This should be just displaying the keymove portion of the 'RM' output.
2. The ability to dis-associate the upgrades. Slightly more complicated, but basically copying the data structure from the upgrade into the 'global' keymoves and then deleting from the upgrade.

That said, we only have a certain amount of developer bandwidth - and if this is just a temporary solution with the full solution being a 'summary' output that shows what is bound to every key including much more than just keymoves (macros, learns, special functions) then time may be better spent rounding out that idea and implementing it.

xnappo

I roger the limited developer bandwidth, and I am just a parasite in this process, but at this point several of the users (I know that vicky has specifically said this, as have I previously) find the absence of the "disassociate" capability a REAL showstopper as opposed to a minor inconvenience. We are encouraged to develop, use, and share complete upgrades whenever we create them, and one of the ways I (and apparently Vicky) do this is to create upgrades for all of my devices, even if they are resident in the remote. Having assigned all of the functions where we want in RM, and uploading to IR, we then can safely delete the actual device upgrade - which merely duplicates what is in the library and is unnecessary - while retaining the keymoves. As RMIR currently limits us, we have to create these keymoves one-by-one using EFCs or Hex commands instead of just assigning functions to buttons on the RM Layout tab. The same has applied to certain protocols in the past. I'm not clear on what "higher-priority" issues in RMIR the development team believes require greater attention at this point, but this particular issue has been identified for well over a year, and although I welcome and applaud the new and improved stuff that constantly is evolving, it is frustrating when longstanding concerns - acknowledging that they have been "accepted" as feature requests - seem to get no real attention.

I guess my question is - how much more "rounding out" does this idea require before it can be squeezed into the developer bandwidth?

[vickyg2003]

The thing is Captain, their premise is that the remote is a collection of upgrades.

To me an ordinary remote is a collection of device codes, but a JP1 remote is an integrated home theater control.

As long as they feel a need to segregate the upgrades, and use this OVERLY device oriented concept, we're totally off the developer's radar.

[The Robman]

Quick bug report. I just tried to verify that RMIR can save files in the *.ir format, so experts can help people that get stuck with RMIR by looking at their setups using IR.exe, and I've found that it doesn't work.

I selected File > Save as and then changed the "Files of type" drop down to "IR files (*.ir)" but the file name still had an .rmir file extension, so I changed that manually to test.ir and saved it. However, when I go back to the folder to find the file, it actually got saved as temp.ir.rmir and opening the file using Notepad reveals that it really is in the RMIR format.

[vickyg2003]

Bug Report preview 4

1)When you do NEW Device, Import, the Dropdown All Device Upgrades, works but the keymap-master doesn't show any TXT files.

2)When you do a FILE->New the little markers for the learned section and the markers for the empty device/protocol protocols section isn't shown.

3)When you add an device upgrade, you are forced to assign it to a key, just like IR does, but when you unassign it from the device key all the keymoves are deleted. This makes it impossible to use helper upgrades and multiplexing.

4) The remote is showing the upgrade area as being used, but the RAW Data tab show all FFs.

5) Can't handle "No JP1.x remote found." error.

6) Unassociating the device upgrade from the Device button also seems to delete the Device from the image. Associated with 3 above.

[xnappo]

The thing is Captain, their premise is that the remote is a collection of upgrades.

To me an ordinary remote is a collection of device codes, but a JP1 remote is an integrated home theater control.

As long as they feel a need to segregate the upgrades, and use this OVERLY device oriented concept, we're totally off the developer's radar.

That is not what I was saying, I was only explaining how the code was written and suggesting that a device view feature might solve the 'keymove viewing' issue and provide additional functionality.

I also agree a disassociate function is needed.

xnappo

[vickyg2003]

The thing is Captain, their premise is that the remote is a collection of upgrades.

To me an ordinary remote is a collection of device codes, but a JP1 remote is an integrated home theater control.

As long as they feel a need to segregate the upgrades, and use this OVERLY device oriented concept, we're totally off the developer's radar.

That is not what I was saying, I was only explaining how the code was written and suggesting that a device view feature might solve the 'keymove viewing' issue and provide additional functionality.

xnappo

Its not what you said, its what Greg said.

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 [in RMIR] 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.

[xnappo]

Its not what you said, its what Greg said.

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.

Okay, but here Greg was only explaining how RM-IR got to where it is I think - not saying it would stay that way.

xnappo

[gfb107]

The thing is Captain, their premise is that the remote is a collection of upgrades.

To me an ordinary remote is a collection of device codes, but a JP1 remote is an integrated home theater control.

As long as they feel a need to segregate the upgrades, and use this OVERLY device oriented concept, we're totally off the developer's radar.

I think that is unfair. We have consistently responded to questions and bug reports. We have made lots of changes based on your feedback. Your statement implies that you have given up on RMIR and its developers.

A remote configuration is not a collection of device upgrades. However, device upgrades are a major component of a remote configuration.

We are well aware that RMIR is not where it needs to be to address your needs. We have repeatedly acknowledged that. We have also acknowledged that RMIR is overly device-centric, and that we will do something about that. We just can't tell you when.

I guess I got too excited about getting to the RDF Feature complete stage. It is a huge milestone for RMIR. Maybe I went too far when I said

We plan v2.00 to be "RDF Feature Complete," which means supporting everything documented in the RDF Specs and addendums, making RM a complete replacement for both IR and KM for "typical" use.

After that we start adding the bells and whistles and advanced functionality that will truly make IR and KM obsolete.

At the time I thought for "typical" use would be meaningful to all of us and give us a common sense of where RMIR stands today and expectations about functionality. I also thought it was clear that more work was needed to address anything beyond typical use. Clearly I was wrong on both counts.

Maybe "simple" or "trivial" use would have been a better choice. To me "typical" means having a few device upgrades (with associated keymoves and protocols) and a few macros, LKPs and DSMs to achieve activity based control.

I have a very nice setup using a 6131 with Extender 1 to control a Samsung DLP TV, a DirecTV HR21 DVR, and DirecTV HR10-250 TiVo, an Onkyo receiver, and a Popcorn Hour PCH-C200. I have 6 device upgrades, which bring along 4 protocol upgrades and 18 keymoves). I have 12 other "cross-device" keymoves, 10 macros, 2 DSMs and 2 LKPs. I used about 1/3 of the available keymove/macro space and 2/3 of the upgrade space.

I think that setup is even a little beyond typical use, and I did it all in RMIR (other than installing the extender, which is on the ToDo list, and is itself beyond typical use in my opinion).

Maybe I am naive, but I don't think "typical" includes

• Installing device upgrades and then deleting them as a vehicle for creating a group of keymoves.
• Replacing protocols with customized versions
• Using every single byte of a remotes memory in order to control 12 devices with an 8 device remote by carefully selecting functions that could be in a device upgrade (based on the keys to which the functions are assigned) and using keymoves and learned signals instead.

I understand and accept the need for all of these. I understand that there are situations in which not having any one of these could be a deal breaker. I do not think any of them constitute typical use.

Please feel free to let me know how completely wrong and unreasonable I am.

[gfb107]

Quick bug report. I just tried to verify that RMIR can save files in the *.ir format, so experts can help people that get stuck with RMIR by looking at their setups using IR.exe, and I've found that it doesn't work.

I selected File > Save as and then changed the "Files of type" drop down to "IR files (*.ir)" but the file name still had an .rmir file extension, so I changed that manually to test.ir and saved it. However, when I go back to the folder to find the file, it actually got saved as temp.ir.rmir and opening the file using Notepad reveals that it really is in the RMIR format.

This have never been something that I thought was a requirement for RMIR. From that perspective, I consider the fact that it let you try to save as an IR file a bug.

That is not to say that RMIR should not be able to save as an IR file. I am just saying that it does not today, but you already know that because it didn't work. Please create a feature request for this.

[gfb107]

My style of dealing with questions and error reports is to explain what I was trying to accomplish when I made a design decision, some details about how I implemented it, and an explanation about how that produced what is being reported.

When I do that, my intent is to accomplish the following:

• Clarify in my mind the details of the design and code, which is likely more than 2 years old
• Give you some understanding of what is happening in order to
• promote discussion and creative brain storming about possible solutions

Too often, this is misinterpreted as my saying "this is how it works, and it's not going to change". I don't understand why that is, but it has happened again and again and again.

Occasionally this has happened just as real life forced me to take a break from JP1 for a week or more, and by the time I get back the discussion is lost, or at least I have forgotten about it. I apologize for not keeping track of those discussions, but I think that is inevitable, at least for someone as disorganized as me.

As I stated before I haven't reprogrammed my remotes in over a year, so I am not working on RMIR because there is function missing I need. I am working on it because in the long run I think it'll help all of you, and all the new users than come along. It is also fun for me (at least most of the time).

[Capn Trips]

The thing is Captain, their premise is that the remote is a collection of upgrades.

To me an ordinary remote is a collection of device codes, but a JP1 remote is an integrated home theater control.

As long as they feel a need to segregate the upgrades, and use this OVERLY device oriented concept, we're totally off the developer's radar.

I think that is unfair. We have consistently responded to questions and bug reports. We have made lots of changes based on your feedback. Your statement implies that you have given up on RMIR and its developers.

A remote configuration is not a collection of device upgrades. However, device upgrades are a major component of a remote configuration.

We are well aware that RMIR is not where it needs to be to address your needs. We have repeatedly acknowledged that. We have also acknowledged that RMIR is overly device-centric, and that we will do something about that. We just can't tell you when.

I guess I got too excited about getting to the RDF Feature complete stage. It is a huge milestone for RMIR. Maybe I went too far when I said

We plan v2.00 to be "RDF Feature Complete," which means supporting everything documented in the RDF Specs and addendums, making RM a complete replacement for both IR and KM for "typical" use.

After that we start adding the bells and whistles and advanced functionality that will truly make IR and KM obsolete.

At the time I thought for "typical" use would be meaningful to all of us and give us a common sense of where RMIR stands today and expectations about functionality. I also thought it was clear that more work was needed to address anything beyond typical use. Clearly I was wrong on both counts.

Maybe "simple" or "trivial" use would have been a better choice. To me "typical" means having a few device upgrades (with associated keymoves and protocols) and a few macros, LKPs and DSMs to achieve activity based control.

I have a very nice setup using a 6131 with Extender 1 to control a Samsung DLP TV, a DirecTV HR21 DVR, and DirecTV HR10-250 TiVo, an Onkyo receiver, and a Popcorn Hour PCH-C200. I have 6 device upgrades, which bring along 4 protocol upgrades and 18 keymoves). I have 12 other "cross-device" keymoves, 10 macros, 2 DSMs and 2 LKPs. I used about 1/3 of the available keymove/macro space and 2/3 of the upgrade space.

I think that setup is even a little beyond typical use, and I did it all in RMIR (other than installing the extender, which is on the ToDo list, and is itself beyond typical use in my opinion).

Maybe I am naive, but I don't think "typical" includes

• Installing device upgrades and then deleting them as a vehicle for creating a group of keymoves.
• Replacing protocols with customized versions
• Using every single byte of a remotes memory in order to control 12 devices with an 8 device remote by carefully selecting functions that could be in a device upgrade (based on the keys to which the functions are assigned) and using keymoves and learned signals instead.

I understand and accept the need for all of these. I understand that there are situations in which not having any one of these could be a deal breaker. I do not think any of them constitute typical use.

Please feel free to let me know how completely wrong and unreasonable I am.

Perhaps some of my frustration has been coming through, and I'm not going to argue the definition of "typical" with you, but to be frank, I did not see anybody clamoring for "RDF feature-completeness" - whatever that is, whereas (as previously-stated) long-standing requests continued to be put on the back burner.

To put it bluntly, I see lip-service being paid to those specific feature requests that are of importance to me and a few other members of this forum, while you continue pursuing program upgrades that (from where I sit) you pick and choose as - for whatever reason - more pressing.

As the developer, you certainly have the right to choose in what order you implement (or not) any changes, but I had not seen any feature requests from other users for 90% of the new features. Do I like them? Sure. Do they make RMIR a better tool? Sure. But I have not seen the NEED for them whereas I have striven to illustrate the NEED for the other feature requests that I have documented in SourceForge.

Regardless, I appreciate your herculean efforts and will continue to download and use every new iteration of RMIR, and will continue to provide my thoughts on it (at least until Rob bans me to Jim Hammel and Elliot Axel-land)