RMIR: Prototype IR function in RM

[gfb107]

Protocols such as extender, DSM and stuff will be visible, others will not, am I reading it right?

No, even the special protocols are associated with a small dummy device upgrade. I really can't think of any case where a protocol would be installed without a device upgprade.

Ok, so there might be a small price to pay initially to actually find the device upgrade files made long ago or will the protocol be visible through RM section when you double click the device in the IR section. Am I reading it correctly?

As it stands today, you can see the protocol code when you actually look at the details of the device upgrade (the output tab).

Will unassembly be there?

Maybe someday.

[gfb107]

Also, how will RM handle the case in which TWO device upgrades use the SAME protocol upgrade? Will the protocol upgrade be displayed with EACH of the invoking device upgrades? Or just with the one from which it was "imported"? Or is the logic simply:
RMIR looks at all device upgrades, if the invoked protocol has a protocol upgrade associated with it, it is alway "suppressed" in the Protocols Tab and displayed with any Device Upgrade invoking it, whilst any protocol upgrade that has no associated device upgrade will appear separately in the Protocols Tab? (If that is so, I like it)

When RMIR imports a .IR file, it discards protocol upgrades that RM would flag as required on the Output tab, so the user doesn't really have to know or keep track of them. RMIR knows that the protocol upgrade is required, knows how to generate it, and will do it automatically.

The only thing that still will be a bit of a nuisance - and likely a bridge too far - is that when RMIR reads a device upgrade and displays in a device upgrade window, it will only display the buttons assigned in the button map for that device, with only the names of the buttons on the remote - not the "proper"function names. I suppose it's unlikely that RMIR will be able to search (perhaps a pre-specified directory) for a "matching" device upgrade, and offer one the option to call up THAT upgrade (function names, keymoves and all) to view/edit is it?

RMIR won't do that automatically. But you can very easily do that. If you have a .rmdu or KM .txt file that is the source of an installed device upgrade, select the upgrade on the Devices tab, then press the Import button and select the desired upgrade file. This will replace the device upgrade imported from IR with the detailed upgrade from the file. Now you have all the details of the upgrade to work with.

Save your imported .IR upgrade as a .RMIR file. When you open it the next time, you'll see that all the details of the upgrades are still there, and can be manipulated directly from inside RMIR. If you want to share a device upgrade, just highlight it and export it to a .rmdu file.

[jetskier]

ooops sorry
Hey, why don't you want protocols to be seen? Because the RM section will have it?

All I am concerned with is the upgrade. The protocol is the code that I am least worried about. If the program can take out that step and keep track of the protocols needed itself, I don't have to worry about it. Granted a note or flag saying the protocol was/is loaded when required would be nice in the device page.

I guess the other way to handle it is to make it an option for the user? "Show Protocols Tab"

[ElizabethD]

I can only pretend I understand some of this discussion, but let's go on, 'cause it's cool unless we're detracting Greg from doing his work.

I cannot remember any circumstance in which a protocol is added that is NOT related to a device upgrade, so Greg's comment about considering removal of the protocol tab completely MAY make sense.

I really can't think of any case where a protocol would be installed without a device upgprade.

Perhaps I can, IF we're talking about the same thing. You want to try two versions of a protocol against one device upgrade (assuming the same hex codes work). You can put both versions into IR now and switch the protocol number on the devices tab for trying out things. For instance, a built-in protocol vs a cooked here one. Or is that ok now?

Question: does java engine allow sideways scrolling like in Excel, without affecting column widths when another column width is changed?

Question: Is there a size limit for reading the eeprom contents? There's a remote with an enormous one, 16 or 24K.

Wish list item: I think someone already mentioned it - it would be great to see a spreadsheet with all the button assignments from the entire remote system as seen by RM-IR. I don't have to know what's on the three versions of each button, real or phantom, just "x" where used. Button names could be in rows. Devices in columns, and button, shift-button, xshift-button in the columns within each device. I think that would do it. Possible?

Wish list item: currently, when I paste device or protocol out of the SpecialProtocols.xls into IR, IR issues an error, because in SP the lines are too long. Four or five tabs at the end of each line. Is that going to be a problem in RM-IR as well? No big deal as it can be stripped in notepad, but is extra step to remember. I don't have this problem in ProtocolBuilder.

Batch files:

This is really pretty basic, isn't it?)

I dunno Always painful without macro recorder like excel has to get the syntax.
But every once in a while the old stuff comes useful on NT, where you run the .cmd (same as batch) files with %1 %2 %3... all sorts of parameters for variable stuff and just one point of change for the code.

[gfb107]

IF we're talking about the same thing. You want to try two versions of a protocol against one device upgrade (assuming the same hex codes work). You can put both versions into IR now and switch the protocol number on the devices tab for trying out things. For instance, a built-in protocol vs a cooked here one. Or is that ok now?

I haven't provided a way to do anything like that, although I think the way I would handle that would be to edit the device upgrade and modify the protocol associated with that upgrade.

Question: does java engine allow sideways scrolling like in Excel, without affecting column widths when another column width is changed?

Yes

Question: Is there a size limit for reading the eeprom contents? There's a remote with an enormous one, 16 or 24K.

There is no coded limit, and there is no special code for handling really large EEPROMs. I guess the limit would be available system memory and swap space.

Wish list item: I think someone already mentioned it - it would be great to see a spreadsheet with all the button assignments from the entire remote system as seen by RM-IR. I don't have to know what's on the three versions of each button, real or phantom, just "x" where used. Button names could be in rows. Devices in columns, and button, shift-button, xshift-button in the columns within each device. I think that would do it. Possible?

Possible. This would be similar to RM's KeyMap tab.It's great to document the wish list items in a thread like this, but I am months away from adding wish list items.

Wish list item: currently, when I paste device or protocol out of the SpecialProtocols.xls into IR, IR issues an error, because in SP the lines are too long. Four or five tabs at the end of each line. Is that going to be a problem in RM-IR as well? No big deal as it can be stripped in notepad, but is extra step to remember. I don't have this problem in ProtocolBuilder.

It shouldn't be an issue, but until it's coded we'll just have to wait and see.

[gfb107]

RM v1.65 addresses some of these issues, and adds more function.

[jetskier]

Looking good Greg. I like how the keymoves associated wtih device upgrades don't appear in the keymove tab. At first I thought there was an error, but after clicking on the device, they showed up again with the note about the importing.

And you fixed the VPT too!

[Capn Trips]

I like it, too. Question. Obviously, there are differences in opening an IR file, and displaying a remote's downloaded EEPROM image. I notice that when opeining an existing IR file, the actual function names for device upgrades are displayed for the keymoved buttons. Does RMIR extract this info from the IR notes column? Pretty clever.

Of course, RMIR cannot determine what the name of the function is for those buttons in the device's default button map, since that info is not resident anywhere in an IR file.

Since I can't use Java IR to up/download yet (JP1 only, here ) what will JavaIR display for downloaded device-related keymoves?

However, in my case, with the "shifting" of device-upgrade-associated keymoves to the device upgrade, I cannot even ACCESS the keymoves tab - it simply won't open. How would I create a keymove in JavaIR without being able to open that Tab?

[gfb107]

I like it, too. Question. Obviously, there are differences in opening an IR file, and displaying a remote's downloaded EEPROM image. I notice that when opeining an existing IR file, the actual function names for device upgrades are displayed for the keymoved buttons. Does RMIR extract this info from the IR notes column? Pretty clever.

Yes. When RM (classic) and KM generate keymoves associated with a device upgrade, the function name is put in the notes, so I though that would be the best thing to do. Of course the notes could have been changed by the user, but there is no perfect solution.

Of course, RMIR cannot determine what the name of the function is for those buttons in the device's default button map, since that info is not resident anywhere in an IR file.

Correct. When the function is in the button map, or there are no notes, RMIR uses the button name.

Since I can't use Java IR to up/download yet (JP1 only, here ) what will JavaIR display for downloaded device-related keymoves?

It uses the button name, just like importing a raw device upgrade (which is what is happening under the covers).

However, in my case, with the "shifting" of device-upgrade-associated keymoves to the device upgrade, I cannot even ACCESS the keymoves tab - it simply won't open. How would I create a keymove in JavaIR without being able to open that Tab?

That shouldn't be happening, would you upload your IR file to the diagnosis area, please?

[Capn Trips]

Here it is.

Specific problems: (recommend viewing in an IR and Java-IR windows side-by-side)
(1) JIR Keymove tab won't open, so I cannot see whether or not a keymove NOT associated with a Device Upgrade is still there (Aux shift-4)
(2) Macros Tab has incorrectly imported two SF keymoves into the top two positions of the Macro list. Macros 3-20 of JIR match Macros 1-18.
(3) Of 42 SF keymoves in IR, only 35 are shown in JIR, and many are "mixed up" - look at the entries for the LKPs for CD number buttons 1-5 in IR, and then find that only CD 1 is there in JIR, whilst the notes for CD 2-5 are displayed with unrelated button assignments.

Edit: More specifically:
(1) SF functions in IR #14 and 16 (LKPs on SAT Fav and Info) were moved into positions 1 and 2 on the macros list in JIR;
(2) SF functions in IR #15, 17-20 (LKP on SAT Guide and on CD 1-4) have disappeared;
(3) whilst SF keymoves 14-20 have been "relocated" the NOTES for only keymoves #14-17 have disappeared and the remaining notes are offset by three entries as a consequence.

P.S. What are we calling this program? RMIR (pronounced "rumour"?)? Java-IR? JIR?

[gfb107]

All of these issues are the result of a problem decoding the LKP keymove assigned SAT:Fav. It's a bug in RMIR's Fav/Scan code.

As a workaround so you can poke around more of RMIR, use IR to either remove that keymove, or assign it to a different key.

I'm calling it RMIR for now.

[jetskier]

I'm calling it RMIR for now.

Remote Master InfraRed? I'd keep it simply named Remote Master when you roll it out. I don't think IR is neccesary as RM says it all. It has a ring to it like all the masters (i.e. key master, thigh master, etc) .

[Capn Trips]

As a workaround so you can poke around more of RMIR, use IR to either remove that keymove, or assign it to a different key.

Bingo! Spot on and timely, as usual.

Thanks.

(Now I can't wait to see it communicate with JP1 remotes!)

Edit: Although, I just noticed that the Move/Macro memory remaining meter at the bottom of the display seemingly only accounts for the Keymoves, Macros and Special Functions that remain on those three tabs, and does NOT account for those Keymoves embedded with Device Upgrades, giving a falsely high display of available Move/Macro memory.

As for the name, I SORT of agree with jetskier regarding the logic and simplicity of his suggestion, but I also see a few likely challenges using RM as the name:
(1) Using "RM" can likely lead to confusion amongst old-time, infrequent users of this forum if and when they return for whatever reason since they will remember the current RM, including similar confusion among posters/searchers of the forum who will see "RM" used in ONE meaning before September 2006, and with a DIFFERENT meaning - likely inconsistently - AFTER September 2006;
(2) Updating all of the current beginner's docs - a notoriously difficult thing to police due to the variety of authors;

So I support RMIR as a shorthand, which "suggests" that this is an alternative to IR but is related to RM.[/b]

[ElizabethD]

I just tried RM1.65. RM side looks great on my IR file for 6131ext. Thanks, Greg.
IR side looks very good, but I just bumped into a protocol issue which did not occur in the RM standalone.

Panasonic Combo 00 CD for main device 160, OEM1=2, OEMdev2=32, fixed bytes BF FB FA.
When I double clicked device upgrade, an RM v1.49 upgrade came in, probably this, or close to it
http://www.hifi-remote.com/forums/dload ... le_id=2022
but the screen thinks it's Denon-K, main device 10 (I saw the same thing in the 1.63 JWS version earlier, that one goofed in RM-only mode). It looks like RM-IR might not be looking beyond 00 CD at the other parameters. When I manually changed it to Panasonic Combo on the setup sheet, it broke in that the main device became blank and all subdevice entries became zero. BTW the linked file may not even be for 6131, but I think you'll see the drift anyway.

For this exercise, I have six upgrade files for that device (Panasonic EN-17), at this point all in one directory. Three are KM, three are RM. How does RM-IR decide what to take for the double click display??
Related question: I know I can load a device upgrade that is the latest, bestest, whatever. But if I need to see what's in the IR section right now, at the point the IR file is opened, this double click method might not give it to me. Does it? Will it when it's beyond prototype?

Please don't call it RM. The same reasons as Capn Trips mentioned. It does need to be different. RMIR is fine by me, as would be RM-IR, RM+IR.

[gfb107]

When you import a .IR file, RMIR uses RM's "Import Raw Upgarde" file to create RM-style upgrades from the raw upgrades present in the .IR file.

The "import raw upgrade" function is not perfect. It won't always pick the right protocol, because there isn't enough information to uniquely identify it in all cases.

Double-clicking a device upgrade doesn't load a pre-exisiting RM or KM device upgrade, it just shows you the result of importing the IR file.

Since an IR file doesn't have all the details of a device upgrade, and can sometimes choose the wrong protocol, the thing to do is go through each of the installed device upgrades and manually load the correct KM or RM file. This will guarantee that there haven't been any import errors, and will also fill in all the missing details (function names, unassigned functions, upgrade notes, etc.) that aren't present in a .IR file.

Then you save it as a .RMIR file, and that contains all the details of all the upgrades, and you never have to go back to .IR again.

Of course, when/if RMIR gets that far, the normal mode of operation won't be to import a .IR file. It'll be how IR is currently used, except that instead of copy'n'paste from KM/RM, you'll just load the KM/RM file directly.