Seeking suggestions for enhancements for IR.exe

[mathdon]

I am currently making enhancements to IR.exe to take account of features of UEI remotes introduced in the URC-7780 and URC-7781. These include (1) correct handling of "soft devices", i.e. remotes that do not have dedicated buttons for device selection but instead use an LCD screen on which you scroll through a list and select with an Enter key, and (2) the new format for macros and timed macros introduced in these remotes, which prevents the current version, 7.15, of IR.exe from displaying them.

I invite users to suggest other enhancements that they feel would be of help. I'm not promising to incorporate them but all suggestions will be considered, either for this next revision or a subsequent one.

[xnappo]

I invite users to suggest other enhancements that they feel would be of help. I'm not promising to incorporate them but all suggestions will be considered, either for this next revision or a subsequent one.

I think my request would require the aid of the extender writers too - but I would like to see a way to make the use of the device multiplexor special protocol be transparent to the user.

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?).

I know RM is a separate project. We have some forced unpaid time coming up at work, maybe I will take a peek

xnappo

[mdavej]

I would like to see a help file included with IR and put on the help menu. Including one of the existing help docs would be good enough. An actual help file would be ideal, but would be a lot of work.

I'd also like to see improved handling of the pause protocol. On remotes that use 2 byte pause, the user has no idea what that 2nd byte should be or that it's even required. The ideal interface would let you enter seconds and IR would sort out the correct hex values depending on 1 byte / 2 byte, processor, etc.

Lastly, although this is a bit out of the scope of IR improvements, but one install package for everything IR would be very helpful. Mark's beginners sticky is very good already, if only it could be taken to the next level and automated somehow. There are a lot of steps and a lot of files involved and newbs often don't get it right. Many programs like spybot can check online for updates or new components and download and install them. I don't know if something similar is feasible in this case.

This is a little OT, but how is the Key Move / Macro Import function supposed to work? I understand key moves could come from KM and be pasted in. But how are macros formatted and what do you import them from? Would some kind of Export be useful, to copy from one instance of IR to another, or would that be impossible to implement?

[xnappo]

This is a little OT, but how is the Key Move / Macro Import function supposed to work? I understand key moves could come from KM and be pasted in. But how are macros formatted and what do you import them from? Would some kind of Export be useful, to copy from one instance of IR to another, or would that be impossible to implement?

An export would have been very nice last weekend when I moved from the Atlas 1.0 extender to 2.0!

xnappo

[vickyg2003]

I would like to see a help file included with IR and put on the help menu. Including one of the existing help docs would be good enough. An actual help file would be ideal, but would be a lot of work.

I'm not sure what kind of built in support Delphi has for context sensitive help, some languanges make this really easy, others make you jump through hoops. One problem with creating a HELP file is VISTA doesn't support standard HLP files, and CHM files are really messy,basically they are a collection of a lot of free form pages. Installation could be a problem with CHM.

[unclemiltie]

Help could/should be pointed to a web page. That way, when the user clicks help, they get a page that can be managed and updated regardless of if/when the user has actually updated their software.

[Edit]Discussion about extender version control split off to separate thread:
https://www.hifi-remote.com/forums/viewtopic.php?t=10521

-bill

[xnappo]

Bill/Vicki,

Any comment on my suggestion to make the device multiplexor transparent to the user? My thinking is that in the RDF you could have CBL2, VCR2 etc that are 'fake' devices. In if you selected the CBL2 button or used X_CBL2, IR would know that it needed to insert a call to a reserved location containing the alternate setup code. The only non-transparent thing here is that the V_CBL/T_CBL etc assignment would be for both the CBL and CBL2 device.

xnappo

[unclemiltie]

First, that would require defining more keys in the extender, which of course wouldn't be all that difficult except for the 8-device remotes where we are running out of space (7 keysets including temporary, 8 devices into a map of 64 slots)


Doing this in the extender would be highly complicated since you would have to swap out the setup codes every time you do one of the x_dev commands to make sure that the right thing was in there. I wonder about extender space given that the code is already pretty tight.

As for doing this in IR so that you could put in say 8 devices for a 5-device Atlas and IR turns that automatically into the right set of keys to call the multiplex protocol, I guess it could be done. I'd have to think about how to make it generic enough to be simple but still flexible enough to do what MPX does today.

[vickyg2003]

What you are really talking about is a phantom device. If you look at your IR file you can see that the setupcodes occupy a contiguous block of memory. These make up an array. The remote uses an index to look up the correct codes. On my Comcast 1067a remote I was able to add two phantom devices because I didn't need the bytes of memory that followed the setup codes. The remote originally used these bytes for VPT and other settings.



Moving the setup code array, or getting the remote to use two different array areas would be really tricky. Besides the tricky part, adding phantom devices confused a lot of users. I had lots and lots of problems with users trying to get the concept of phantom devices.

[xnappo]

What you are really talking about is a phantom device.

Yeah, that is true - I made a lot of use of the phantom devices on the 8910 extender. Bill - are phantom devices possible on the Atlas? Sorry for moving off the thread topic!

xnappo

[vickyg2003]

are phantom devices possible on the Atlas?

Unlike a JP1 remote, ANYTHING is possible with a JP1.2 or JP1.3 remote.

Worth the effort? That's another question entirely.

[mathdon]

First, a comment to Vicky about Vista and .hlp files. Vista as delivered does not support .hlp files, but a download is available to make it do so. See MS KB917607 here. When I first used IR.exe I was surprised to find that the Help menu doesn't provide any help, it only has the About entry. I would like a help system of some sort available from the Help menu and will look into this. Personally I prefer a locally held help file that is consistent with the user's version of the software, rather than a pointer to a web page that is regularly updated.

I'm glad that the Fixed Data method of dealing with the selection of RDFs for multiple extender versions works. I'll put this into my next RDFs. I don't want to change the signature whenever the RDF changes. My extender, currently version A1, has the "A" in the signature and the "1" in a version byte. (I thought Vicky did likewise.) I only want to change A to B if I develop a significantly different extender (or someone else does so), not if I make enhancements that may require changes to the RDF.

I don't understand xnappo's issue with Device Multiplexor. Which user is it that he wants it transparent to? The user of the remote, or the user of IR.exe? Surely it is already transparent to the user of the remote, if you set up appropriate macros. Before I created my extender I had two devices, RCV and RCV2, for Zone1 and Zone2 of my Onkyo TX-SR 606. With my extender I need only one device, RCV, and I switch between zones 1 and 2 with buttons A and B on the remote, in exactly the same way that one switches between them on the Onkyo remote. What am I missing?

I also don't understand mdavej's issue with the Pause protocol. This seems to be an issue for the extender writer and his/her documentation, rather than for IR.exe. I say in my manual that you enter the required pause as a 2-byte hex value that is the number of milliseconds of pause that you want, e.g. $03 $E8 for a 1-second pause ($03E8 = 1000). I also say that you can use the Windows calculator in scientific mode to convert decimal to hex. Perhaps not absolutely ideal but pretty easy to understand, surely.

Finally Bill's point about wanting to be able to put the address of the XShiftKey and similar settings into the .hex file rather than the RDF. I see this, too, as an issue for the extender writer, not IR.exe. I have followed Vicky and put tags into my assembler source that mark these bytes, as well as tags that mark the ExtInstall sections. I then have an MS Access program that reads the list and binary outputs from the assembler and generates both the .hex file and the appropriate RDF entries. Here is the unedited output for the RDF:

[Settings]
Timed TogBits=$1DD.7.8.0.0
Shift Key=$2C2.7.8.2.0
Alt Shift Key=$2C5.7.8.130.0
Alt Shift=$2C9.7.2.0.1 (XShift;Shift)
Macro Delay Hi=$351.7.8.127.0
Macro Delay Lo=$354.7.8.127.0

I can let you have the MS Access program if you like.

I await comments on these comments!

Graham

[vickyg2003]

First, a comment to Vicky about Vista and .hlp files. Vista as delivered does not support .hlp files, but a download is available to make it do so. See MS KB917607 here.

Yes, but the user that's going to NEED help, is going to have difficulty finding and doing the download. I have a HLP project for IR that I started but never finished. I'd be happy to help with either type of help.

I don't understand xnappo's issue with the Device Multiplexor.

Phantom devices are easier to use than multiplexes because they carry keymoves and special protocols for the device.

[mdavej]

I also don't understand mdavej's issue with the Pause protocol. This seems to be an issue for the extender writer and his/her documentation, rather than for IR.exe. I say in my manual that you enter the required pause as a 2-byte hex value that is the number of milliseconds of pause that you want, e.g. $03 $E8 for a 1-second pause ($03E8 = 1000). I also say that you can use the Windows calculator in scientific mode to convert decimal to hex. Perhaps not absolutely ideal but pretty easy to understand, surely

I wish pause were that simple in the atlas extender. In that case of an S3C8 or S3F80, the duration byte = seconds x 10.66. So a 1 sec pause would be approximately 10 or $0A. Pretty simple so far. But the second byte is supposedly some sort of key code, which turns out to be $62 in RM, no matter what key it's assigned to. I have no idea what that value really means or how it's calculated. So the 2 bytes for a 1 sec pause would be $0A $62.This is how it's documented in the standalone pause protocol in RM. It's not documented in the extender. Here's what I really don't understand. Say you round up the duration byte to 11 or $0B. The second byte changes to $5A. I don't understand it, and I don't think the average user can understand it either. It's not a big deal to let RM do all the calculations, but it would be better if IR could do it, IMO.

[xnappo]

I don't understand xnappo's issue with the Device Multiplexor.

Phantom devices are easier to use than multiplexes because they carry keymoves and special protocols for the device.

Exactly. Device multiplexor ONLY gives you the the ability to switch between upgrades, while phantom devices give you access to shifted keys and special protocol assignments. With the biggest weakness of the Atlas being the number of devices, and with the Atlas having tons of buttons that could be used to select a device, phantom devices seem like a really useful feature.

Now... Back to IR - what about my idea to have a button in the Devices tab of IR that launches RM(if not already open) and loads the correct upgrade? Obviously a new path to 'upgrades' would need to be added to the config, and the filename of the upgrade would need to be encoded. I think with the modern day equivalent of a COM object (sorry I am no Windows programmer) passing information between that two tools should not be TOO difficult, at least less difficult than really integrated the two.

xnappo