Seeking suggestions for enhancements for IR.exe

[mathdon]

No, it's not being totally rewritten - heaven forbid! But I've taken over its maintenance and had a substantial chunk of additions I needed, to make it compatible with the URC-7780/81 which differ from other devices in several ways. In particular, they don't have dedicated device selection buttons but instead you scroll through a list (with your own choice of device labels, and with any number of devices from 1 to 12) on an LCD screen and select by pressing Enter. They also use a new encoding for macros that enables ordinary macros and timed macros both to exist in the general advanced code area. While I am at it I thought I might as well see what other suggestions were out there for enhancements.

Any suggestions welcome, from trivial to substantial. No promises to do them. but I would like to see what users would like.

About Mike's issue, my intention would be that if you prefix the protocol in the RDF with a minus sign it will select the default device. If that device exists as an upgrade (or even in ROM) with a different protocol then the special protocol will fail - but that is inevitable if you call upon a default. If you have a better suggesion for handling such a clash, please tell me.

[ElizabethD]

My wishes are mostly related to editing and testing IR files upstairs/downstairs/another house:
1. DSM device in 6131 and Atlas already covered - I think Mike will be better to suggest HOW (while I remind myself details of what/how it does now).
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.
3. Some option key to permit expanding a macro to better reflect what's in a macro. By way of example, if a macro contains keys A,B,C, it's sometimes helpful to see details. A temporary display might be A(D,E), B(F,D,G),C where D,E are keys called by macro A ... but as I write it, due to unlimited nesting possible, I suspect it's impractical really
4. Key finder. I sometimes need to know if a key has already been used in base codes or keymoves or macros.
5. Keymoves maintenance would be easier if multiselection was allowed. Select all to, for iinstance, delete all keymoves; select several to move up or down as a group.
6. For testing, an enable/disable flag would be very useful on keymoves (include SP) and macros. Less useful to me, but some people suggested it ages ago, that protocols and devices be included as well. The way I envision it, is to have a checkmark column. You could be trying three versions of a macro and instead of retyping/reloading the trials, and getting confused which file is which, only the 'enabled' one would be going into the eeprom. I suppose a similar effect could be had with being able to copy a macro or keymove definition out of another IR file, but not sure about it.
7. Possibly review the USB code for jp1 remotes which use Delcom driver. I can't make it work on my XP, one of 3 computers. Remote is recognized, but misses data segments. Maybe something obvious will jump out that's an issue with IR rather than the always suspected Delcom driver. Perhaps it would be possible for IR to say what the last URB status packet was, including the eeprom address, so we can tell Delcom where things fail.
8. Probably nothing causes more confusion for newcomers than the headings on the keymove sheet. Could we rename/edit the second instance of DeviceButton, the one refering to the upgrade device, not the bound key.
9. On RawData tab, a Find command for a sequence of bytes would be nice.

[mr_d_p_gumby]

Mike is refering to this (from the 6131 extender help files)

Version 6 of the IR program introduced a new Special Protocol Functions tab
where you can enter and edit the data for special protocols in a user-friendly
manner. Unfortunately, IR does not recognize the built-in DSM in this extender.
You can always enter the DSM keymoves using other means, but if you would
prefer to work in IR, you can use this workaround.

Copy & paste the device upgrade below into IR, then enter your DSM data on the
Spcl Prot Fns tab. When you are done, delete the device upgrade.
Upgrade Code 0 = 1C 4F (TV/1103)
FC
End

(Nice one Liz! Using my own words against me! )

Liz is, of course, correct. It is the dummy device upgrade that is needed to activate the DSM functions. It's been a while since all this transpired, but I now remember that the problem was that Mark (Pauker) did not want to have the device setup code in the RDF. At the time, I had proposed to use the setup code instead of the PID in the SP entries.

The problem with what I suggested this time (negative PID) is that you would have to hard-code the setup codes in IR, which is probably not a good idea. Maybe we could consider allowing an alternate syntax for the entries:

Code: Select all

[SpecialProtocols] 
LDKP=01F9 
ToadTog=0181 
Pause=01FB 
DSM=TV/1103:01FC
Multiplex=01FE

This way, IR knows the PID and the setup code, and would also know to skip the check for presence of the device upgrade and the protocol upgrade. (Similar syntax is used in the [Buttons] section where optional data precedes the item and is delimited with a colon.)

[mr_d_p_gumby]

I guess I have to question whether this option (PrioritizeMacros) needs to be in the RDF or would it be better implemented as one of IR's built-in advanced functions?

To Mark Pierson: I think the PrioritizeMacros should be in the RDF since it is presumably an option that you wish to exercise either always or never for some particular remote. If it is in the Advanced Functions you would have to select it every time you entered IR, or if the setting is remembered in the Registry, then it would apply to ALL remotes. To have it on a remote by remote basis, the right place seems to be in the RDF.

Both opinions seem to me to have merit, but I'm tending to lean more towards Mark's thinking here.

This option would primarily be for use by an advanced user, whom I think would be capable of either editing an RDF file or checking an advanced option. However, the function seems more related to controlling program operation than to defining the remote, so for that reason I think it should be an advanced option in IR. Also, when the user updates to the latest RDF file distribution, he would have to remember customize the new RDF again (something that we've occasionally had trouble with in the past).

[The Robman]

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.

[mathdon]

I've now implemented Mike's suggestion to allow for special protocol entries like

DSM=TV/1103:01FC

when the device upgrade is absent. Since I had already done so, I've also implemented Mike's original request, suppression of the message about needing to load the protocol, when the protocol is absent and its ID is prefixed with a minus sign, such as

ToadTog=-0181

Someone may find a way of putting the special protocol other than in the upgrade section and I can see no harm in leaving it in.

I've also implemented something of my own - read-only settings. An entry like

StartReadOnlySettings = 10

in the General section means that the 10th and later entries in the Settings section become read-only. My reason is that I feel that loading an RDF on its own should, ideally, put IR in the factory reset state of the remote. There tend to be a few settings that need initializing to achieve this that the ordinary user shouldn't touch - or indeed ones whose purpose is unknown. I could suppress them entirely from the visible settings section but I felt there are advantages in being able to read their values. Does anyone see any problems with this?

[mathdon]

In response to a wish of Vicky's to be able to have, say, two ToadTogs, Mike wrote:

I tried this by adding a second ToadTog entry, etc., but both show up named 'ToadTog', which could be confusing. IIRC, IR will only recognize specific names on the left side of the equals sign, and those names control how the special protocol is defined and operates within IR. Rather than expand this list of SP names, maybe IR could be modified to allow for an optional SP name to be defined in the RDF using a syntax like this:
[SpecialProtocols]
ToadTog=0181,ToadTogA
ToadTog=0182,ToadTogB
This name would then be used to populate the Type drop list & column on the special protocols tab.

Vicky subsequently wrote

I can always get these constructs by building them by hand. They used to do that before IR had the functions built in. Maybe I should think this through more thoroughly before you spend any time on that.

It seems a nice idea, however, even if one just wants to change a name to something more transparent without needing two of them. So I've done it, with a slight variation. Mike's syntax doesn't cope with special protocols such as LDKP, where there are two functions in one protocol. So I have the new names as a bracketed list, even if there is only one name. So, say

Code: Select all

LDKP=01F9 (Long, Double)
ToadTog=0181 (ToadTogA)
ToadTog=0182 (ToadTogB)

will rename LKP as Long, DKP as Double, and give two ToadTogs that show up as ToadTogA and ToadTogB. If in the first example, you only put (Long) then LKP becomes Long but DKP remains DKP.

I've also accepted the majority view about PrioritizeMacros and have turned it into an Advanced Option rather than an RDF entry.

I would like to do something about the Pause special protocol. mdavej wrote

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.

but I don't understand this second byte any more than the users he mentions. Can anyone point me to some info that would explain it?]

[unclemiltie]

The Pause protocol for the JP1.3 extenders (and the URC-9960B01) were implemented different than all of the other pause protocols.

The others the times varied by the processor clock speed used in the remote so the user had to tinker with the pause value and figure out how long they wanted it.

On these extenders, I did some rudimentary timing and set a value in the extender for a 100ms pause. The pause value that the extender gets from the remote is the number of 100ms pauses that it should do, ie: time in seconds *10 (thus $0A is an approximate 1-second pause)

The other thing that happened is that the underlying remote did some changes back when the 9960B01 came around and I had to change the way that the pause value was passed. The reason is that in these newer remotes, the remote can do keymoves that are either 3-bytes long and are moving a key value or 4-bytes long and moving a hex command.

In order to get the pause protocol called, I had to use a 4-byte (well, maybe had is too strong, but I could never get the 3-byte to work) This is fuzzy since I'm dusting off cobwebs from when I wrote the 9960B01 extender.

I also chose to NOT use the pause value as a Word and used a single byte to make the protocol as small as I could. I figured that a pause longer than 25.5 seconds wasn't going to be used. Thus the second byte of the keymove data, although passed, is ignored.

Anyway, it would be cool if IR would allow you to input "how long of a pause" and would figure out the correct values to fill in. There could be an RDF entry that helps it compute the pause value (i.e. what is the value of 100ms) and if that is in there, it computes the value for you. If not, it does it the old way.

I could then update the RDF's for the JP1.3 extenders to include this as well as the 9960B01 and 6960. I don't think that my pause protocol was used anywhere else.


PS. Truth be told, I haven't timed the Atlas and RS 15-13x 100ms values yet. They were close when I looked at them and counted in my head so I never changed them.

[vickyg2003]

Quote:
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.

On my old JP1 remote, the pause protocol requires 1 byte of information to set the time. On all of my JP1.2 remotes, if the protocol is only followed by the 1 byte of information, the remote thinks its and EFC on the base setup code so the pause button doesn't work, because the pause protocol is never activated.

Which byte works with the Pause protocol is up to the protocol author. Depending on how the pause was implemented, the first, second or both bytes could be used.

[The Robman]

I'd like to see some new navigation buttons under the Menu bar in IR, somewhat like the ones you see in Excel, Word, etc, which would let you open a file, save a file, upload to the remote, download from the remote, etc.

Here's a mock-up with a few buttons added:

[unclemiltie]

I remembered another that would be useful for me as an extender writer who is always doing the same thing over and over in IR. The ability to "record" and "play" a macro of a series of commands

For example, every time I build an extender during debug, I do the following:

1: run a batch file that builds it

2: in IR open the last file opened (File-recent-0)
3: set that as the baseline
4: upload it to the remote



If I could record a macro that did those three things by pushing on a "macro" button that would be way cool and save me a lot of hassle when I forget to do one of the things that I always do...

But I'm probably in the minority here since most people don't generate their IR file somewhere else and repeatedly upload it.

[mr_d_p_gumby]

II would like to do something about the Pause special protocol. ... but I don't understand this second byte any more than the users he mentions. Can anyone point me to some info that would explain it?]

This is really not an issue specific to the Pause protocol, though it certainly affects it. This is a keymove format variation used in the newer remotes. Keymoves used to accept any valid number of hex bytes, but UEI made a change such that keymoves may now contain only one or two bytes.

If only one byte is present, the byte is a button number, and that button will be looked up in the referenced setup code. The hex byte assigned to that button in the setup code is retrieved and passed to the protocol. This format is obviously not very easy to use in the case of the Pause protocol.

For these remotes, the only alternative is the two-byte keymove format. There are variations in this format among remotes, but the main point is that the two bytes are passed to the protocol unmodified. UEI's convention here for protocols that only use one byte of data is to place the hex value in the first byte. The second byte is not really used, but some remotes put the EFC value of the first hex byte into the second byte, while others just leave it at a random value.

For purposes of the Pause protocol being discussed here, the hex value should be put in the first byte, and either 0 or the EFC put into the second byte.

[mathdon]

I'm afraid I didn't give the most informative quote about the Pause protocol issue. I know about the one-byte-equals-key, two-bytes equals-hex-code issue, which makes every special protocol need at least two bytes in its body part. My extender is like that, which is why I use a two-byte time value (= pause in milliseconds) - not because I think anyone wishes to set the pause that precisely. I explained this to mdavey but he wrote back:

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.

Its these specific values $62, $5A etc needed for the second byte, that appear to have nothing to do with the actual length of the pause, that I don't understand. Or has mdavej got it wrong?

[mdavej]

I think I understand now. What Bill and Mike are saying is that byte two is a don't care in this case, so it could just be zero. Is that right guys? So although RM is calculating something beyond my comprehension for that second byte, it doesn't really matter.

[unclemiltie]

mdavej
correct, the protocol in the extender does not even look at the second byte.


mathdon

like I said in the previous post, I haven't really spent time doing detailed timing on the 100ms number in the JP1.3 extenders. I did it for the 9960B01 which was an older processor so it may be off a bit. I'm happy to tweak it but just haven't had the time to do the precise timing of the protocol