Seeking suggestions for enhancements for IR.exe

[mathdon]

Mike, I'm aware of the issue of setup codes from 2048-4095 and have caught some of the issues. I've removed some of the prohibitions as I've gone along, so that they can be entered and displayed on the Device Buttons panel of the General page (it seemed as if they could be entered, but not displayed), but it looks as if I haven't found all of them. I haven't looked at the Add/Edit functions on the Devices page, but will do so. But I'm not clear about this heading "Upgrade Code2". Is that something output by RM for such remotes? (I'm afraid I'm not familiar with KM. Is its output similar to that of RM?).

You raised the issue of needing to ask me in due course about the RDF Spec updates that will be required, so that you can update the "official" spec. I think you won't have any trouble. I've written an addendum to the pdf spec dated Oct 12. 2007, in the same style, in the hope that you will be able to import its paragraphs into the relevant places without much amendment. I think the time has come to abandon the earlier .doc file of April 2006 and the rather lengthy amendments to that which have been included in releases of IR.exe so far. Unless there is a later version of the pdf that I haven't seen, it still has big red lettering saying "What does this section do???" under [StaticUpgrades], but does it matter if it is made more public with this in it? What do you think?

[mr_d_p_gumby]

But I'm not clear about this heading "Upgrade Code2". Is that something output by RM for such remotes? (I'm afraid I'm not familiar with KM. Is its output similar to that of RM?).

KM & RM outputs are (in theory) the same, so my reference to KM also applies to RM.

The Upgrade Code2 heading is only possible for those remotes that store both PID bytes at the start of the upgrade, so yes, you will only find it used with remotes also capable of the higher setup code numbering.

You raised the issue of needing to ask me in due course about the RDF Spec updates that will be required, so that you can update the "official" spec. I think you won't have any trouble. I've written an addendum to the pdf spec dated Oct 12. 2007, in the same style, in the hope that you will be able to import its paragraphs into the relevant places without much amendment. I think the time has come to abandon the earlier .doc file of April 2006 and the rather lengthy amendments to that which have been included in releases of IR.exe so far. Unless there is a later version of the pdf that I haven't seen, it still has big red lettering saying "What does this section do???" under [StaticUpgrades], but does it matter if it is made more public with this in it? What do you think?

I quite agree that the two RDF spec documents curently distributed with IR are out of date. I had begun a revised document some time back with an eye towards replacing those docs, but I have not finished it up yet. Have you looked at the newer document?

[gfb107]

Just out of curiosity, has any one been considering impacts to RM and RMIR?

Do the RDF changes cause any problems for RM? Has anyone tried RM with these modifief RDFs?

Is anyone looking at implementing these same features in RMIR?

[gfb107]

Of course, I would like to eventually see RM-IR and RM get merged(like click a button on the tab in RM-IR where a device is defined and it brings up the upgrade in RM -- actually I suppose this COULD be done between regular IR and RM with some work?).

RMIR does this already. See https://www.hifi-remote.com/forums/viewtopic.php?t=6741

Device Upgrades - When you double-click a device upgrade, you get an RM-like dialog that lets you directly manipulate the functions and assignments. Note that when importing a .IR file, it uses RM's raw upgrade import code, so you'll want to select an upgrade then use the Load button to load the RM/KM file you originally used to get the actual functions names and notes. You can also export a device upgrade to a .RMDU file.

[gfb107]

2. When device upgrade comes into IR from KM or RM, could the device tab be expanded to show NOTES entered in KM or RM? Will be useful when unrelated functions are assigned to buttons and button names then make no sense. Currently the only notes that come in are those on keymoves. And include notes if Copy to clipboard is used.

This is a good idea, but KM and RM would also need to change to include those notes as they're not part of the block that is currently copied over from RM/KM to IR.

RMIR does this already

[mr_d_p_gumby]

Just out of curiosity, has any one been considering impacts to RM and RMIR?

Yes, absolutely, when discussing changes to IR, I always keep the impact on RM & KM in mind.

Do the RDF changes cause any problems for RM? Has anyone tried RM with these modifief RDFs?

As long as RM ignores any unknown entries in the RDF, the changes being discussed here should have no impact on RM.

I would hope that RMIR would be updated, as your time allows, to include the changes to the special protocols. I had thought the changes for 2-byte PID handling had been done some time ago.

[gfb107]

I'm just disappointed that once again there's significant effort being made to enhance the old JP1 software. There's no effort to turn RMIR into a complete replacement for IR, and not even an attempt to reach out to me and tell me about it. I can't watch the forums all the time. There will be lots of threads that I miss. I've ranted about this before, but I guess no one got the message.

I put a lot of work into RM (over 187 releases since Feb 10, 2003!), and it's awfully close to being a complete replacement for KM.

I also worked really hard on RMIR, which isn't as close to being a replacement for IR, but really isn't that far away if I got just a little bit of help. It's as much about keeping me engaged and interested in the project as it is about sharing the work load.

I'm just amazed that in the time I've been working on RM there have been 3 Pascal/Delphi coders step in and pick up IR for a little while, but there hasn't been a single Java code come along and help me with RM/RMIR.

[mathdon]

Greg, it might be something to do with the fact that the existence of RMIR seems to be a closely guarded secret. Until its first mention in this thread, a few days ago, I was completely unaware of its existence. I've just opened RM again and tried to find some way of accessing its IR-like functions, with no success. How DO you get into them?

I'm an experienced programmer but not a Java programmer, but then neither was I a Delphi/Pascal programmer. I picked up Delphi/Pascal in order to make the enhancements to IR that I personally wanted, and then continued with other suggestions when Binky was happy to hand maintenance over to me. It might have been Java and RMIR if I had known of it, but now I've mastered Delphi I will continue with IR.exe for the time being.

[gfb107]

It's not a closely guarded secret.

There's a dedicated thread in the Software section about it ( https://www.hifi-remote.com/forums/viewtopic.php?t=6741 ).

It's mentioned in over 50 threads.

[mathdon]

OK, Greg, I'll change that from "closely guarded secret" to "obscure option". I would have hoped for a button, or menu option, to enter RMIR but instead I need a command line option, something normally required only for really specialist, developer-like options. I've just tried issuing "remotemaster.jar -help" from the directory containing remotemaster to see if that tells me about it, but it gives nothing, so I think it is fair to call it obscure. But now that I'm in the secret I see that I can open it, and I will try it.

[mathdon]

I've added a further feature to the Special Protocols syntax today that I hope will be the last. When I was writing the URC-7780/81 extender I realised that there is unused capacity in the data storage format for macros (and multi-macros). The second byte of the 3-byte header for a macro (for remotes that have AdvCodeBindFormat=LONG, I haven't looked at those for which it is NORMAL) has its high nibble encoding the fact that it is a macro, but the low nibble is set by IR.exe always to $F. If you instead set this low nibble to a Device Type Number you get an encoding of a Device-Specific Macro that is almost free of overheads to implement. I implemented this in my extenders but also put in a "standard" Special Protocol DSM as there was no way of activating the "cheap" one in IR.exe, other than by editing the raw binary. The multi-macro headers could be treated similarly to give implementations of other special protocols without the overheads of a device and protocol upgrade. I've now introduced a syntax of the form

Code: Select all

[SpecialProtocols]
DSM=Internal

which can be followed, as usual, by an optional user-specified name in brackets, to support such "internal" special protocols. Only DSM is currently supported (extending the macro header) but I've made it easily extendable to other "internal" special protocols (extending multi-macro headers) if anyone implements them.

[mathdon]

I've revised the support for internal Special Protocols described in my last posting so that this format can be used for any special protocol. The minor change to the syntax is that it is now of the form

Code: Select all

[SpecialProtocols]
DSM=Internal:0

where the 0 following the colon is a serial number in the range 0-5 or 0-4 depending on whether the macro coding format is type 1 or 2 (the latter so far only being the URC-7780/81).

I've also dealt with the issue of device codes 2048-4095 raised by Mike. These can now be entered in the Device Buttons and Key Moves panels for remotes with 2BytePID=Yes in their RDF. Device codes in this range are also accepted, for such remotes, on importing a device upgrade from RM/KM, provided that the upgrade heading is "Upgrade Code2". I hope this is Mike's intent. However, I cannot persuade RM to produce an upgrade with a code in this range. I am using version 1.86 and I see that 1.87 is available, so that may fix this. I've tested such an upgrade by manually editing an RM one, and it does work.

I am closing the development of version 8.00 at this point. Suggestions not yet implemented will be considered for version 8.01. I will post a beta version of 8.00 shortly, with a link from this thread. The package will include new RDFs for URC-7780 and URC-7781 and their Extender A1, a revised RDF specification in two documents (a main document by Mike England and an addendum by me, replacing the two text documents that have been included in earlier releases), Release Notes describing the new features and notes for URC-7780/81 users describing how to use the features that have been specifically added to support remotes with "soft" device selection.

[vickyg2003]

Beta use at your own risk

[gfb107]

Further RM/RMIR discussion continued here

[unclemiltie]

Hey Graham, thought of another enhancement that would be nice for me in IR.


I often am looking for the "data" for a macro, keymove, etc in the raw data. The way that I find it now is that I 'll set the baseline, change the key, then see what changed. I do this when I'm trying to debug an extender issue and I need to know the address of something that isn't quite working right as I try to chase down what is going on.

It would be really useful if there was a right-click on an item in the Macro, keymove or special protocols tab that was "highlight in raw data" IR would then switch to the raw data tab and somehow highlight the data for that macro, keymove, or special protocol. (I guess learns would be useful as well, but I don't much pay attention to those)