IR.exe v8.00 Beta now posted

[damir]

Damir, I've allowed more space for the items you marked. Please say whether you now get everything displayed in full.

Yes it's fine now, thanks.

[The Robman]

BTW There are two icons in the list that I don't recognise. They are the second one, and the last but one (though that one looks vaguely familiar, too). In case they too come in handy some time, what are they for?

If you do a right-click on the icon and select properties, the name of the file should give you a clue as to what it's for. The first one is for executables and the last one is for images.

[ElizabethD]

Thanks, Graham.
Now, here are two more things to make sure you don't use that #13

RC3
8910, 9910, HPPro have a way to display device name on the LCD screen.
RDF for CPT0CPTx1 entry is
DeviceSetup=MISC/1107,ModeName and the protocol is ModeName=01F8.
When I downloaded from 8910, on the SP sheet Type said "unknown".
When I loaded last configuration file, it also said "unknown".
When I add new custom name keymove, it stays on the SP sheet, and also says "unknown".
In IR7 it used to say "ModeName".

When the time comes to select a remote, I still can't see the full RDF filename, usually the significant part at the end is not visible. Could we please just make that window much, much wider. I have that trouble with the 6131 and 8910 RDF names. Yes, switching between the two views helps, but not much. I use standard character sizes.

[mathdon]

Mike, there are still a few minor points to be made about your latest RDF4 Specification.

p.7 In AdvCodeFormat I suggest adding to the sentence near the end reading "If two hex bytes are needed, then both bytes contain the hex values", the addition being "and this two-byte value may be either an EFC or a hex command". The example then needs to say "For remotes using this format with a two-byte value being an EFC, specify the following:". [The reason for this suggestion is that the URC-7780/7781 has a one-byte value being a KeyCode and a two-byte value being a straight hex code. The default HEX handles this case.]

p.13 The description of SoftDev EmptyButtons parameter is wrong. For remotes with soft device selection, device slots can always be empty. It should say:

EmptyButtons determines if settings that reference device buttons may be empty.

Similarly, the expanded text should be:

EmptyButtons should be set to Y, Yes, T, True, or 1 if the remote allows settings that reference device buttons to be empty (set to $FF instead of a button number). If this parameter is omitted (or set to N, No, F, False, or 0), then all such settings must be filled with a button number. The settings concerned are those in the [Settings] section that specify the DeviceButtons section name as a list of choices.

and the final sentence of the SoftDev section needs to be "This signifies that the remote uses soft device selection, it permits the user to leave empty those settings that reference device buttons, the number of filled device slots is stored at $2C and the mapping of the LCD display order to slot positions starts at $A0."

Two comments that don't affect the document. On p.12 you say that if a [SetupCodes] section is not present then the SetupValidation entry will be ignored. It wasn't so - an absent section made every code invalid. I've just changed this for the forthcoming RC4 as your way is better. Also, you say on p.40 about the [SetupCodes] section that normally the entries are listed in numeric order, but that is not mandatory. True. They really don't have to be in numeric order as IR sorts the codes into numeric order for display purposes.
__________________

Graham

[mathdon]

Another item for Mike. I forgot to say that there is a question concerning [SetupCodes] and the DevCodesOffset entry of the [General] section that needs a mention. If DevCodesOffset is <> 0 then the values in the [SetupCodes] section are the internal setup codes, not the codes as displayed on the remote and in the DeviceButtons panel of IR.
____________

Graham

[mr_d_p_gumby]

p.7 In AdvCodeFormat I suggest adding to the sentence near the end reading "If two hex bytes are needed, then both bytes contain the hex values", the addition being "and this two-byte value may be either an EFC or a hex command".

OK, just to make sure we are in sync here, this is how this works. Maybe we can come up with a clearer way of stating the situation.

The two basic types of keymoves alowed in these remotes are:

1) 1 byte, where that byte is a button number; the remote then behaves as if that button had been pressed, using the setup code referenced in the keymove. This type of keymove always behaves the same way.

2) 2 bytes, where one or both bytes contain some sort of command data.

The 2-byte keymove has three variants:

A) AdvCodeFormat=EFC, AdvCodeBindFormat=SHORT
Example: URC-6131, Atlas URC-1054 (unextended)
In these remotes, the first byte is always 0, and the second byte is a single EFC byte. The remote pre-processes the second byte before loading it into the protocol buffer by calling a routine to do EFC-to-HEX conversion. This type of keymove is limited to 1-byte commands (3-digit EFCs).

B) AdvCodeFormat=EFC, AdvCodeBindFormat=LONG
Example: URC-9960B01
This type of remote can process either a 1-byte or 2-byte command. A 1-byte command is encoded the same as type A. A 2-byte command uses both bytes to store a 5-digit EFC value. The remote pre-processes both bytes before loading them into the protocol buffer by calling a routine to do EFC-to-HEX conversion. This type of keymove is limited to 1-byte or 2-byte commands (3-digit or 5-digit EFCs).

C) AdvCodeFormat=HEX, AdvCodeBindFormat=LONG
Example: All JP1.2 & JP1.3 remotes
This type of remote can process either a 1-byte or 2-byte command. A 1-byte command stores the hex command in the first byte; the second byte is unused (but must be present). A 2-byte command stores the hex command values in both bytes. The remote does not do any pre-processing on the hex values; it always loads both bytes into the protocol buffer. Despite the fact that more than two byte commands could be handled readily, because of the logic UEI chose to use, this type of keymove is limited to 1-byte or 2-byte commands.

Does this about cover it? I could also add a similar discussion of the original keymove format.

BTW, part of the confusion on variant C keymoves comes from early experimentation with JP1.2 remotes. We would enter a 1-byte EFC (00xxx) and would see the EFC in the second byte, so we assumed it was requred. Mark even went so far as to modify IR to recognize these as 1-byte commands. Further experimentation proved that the second byte was ignored, and so he removed that logic from IR. The fact that the second byte was the EFC is simply because it was left over data from entering the EFC on the remote.

p.13 The description of SoftDev EmptyButtons parameter is wrong. For remotes with soft device selection, device slots can always be empty. It should say:

EmptyButtons determines if settings that reference device buttons may be empty.

Similarly, the expanded text should be:

EmptyButtons should be set to Y, Yes, T, True, or 1 if the remote allows settings that reference device buttons to be empty (set to $FF instead of a button number). If this parameter is omitted (or set to N, No, F, False, or 0), then all such settings must be filled with a button number. The settings concerned are those in the [Settings] section that specify the DeviceButtons section name as a list of choices.

and the final sentence of the SoftDev section needs to be "This signifies that the remote uses soft device selection, it permits the user to leave empty those settings that reference device buttons, the number of filled device slots is stored at $2C and the mapping of the LCD display order to slot positions starts at $A0."

OK, so the EmptyButtons parameter only affects IR's UI, not data in the remote image, correct?

On p.12 you say that if a [SetupCodes] section is not present then the SetupValidation entry will be ignored. It wasn't so - an absent section made every code invalid. I've just changed this for the forthcoming RC4 as your way is better.

I agree, that will result in less problems.

Also, you say on p.40 about the [SetupCodes] section that normally the entries are listed in numeric order, but that is not mandatory. True. They really don't have to be in numeric order as IR sorts the codes into numeric order for display purposes.

Having them in numeric order in the RDF file makes it easier to visually inspect the RDF for correctness, but I noted that it is not required as I saw that IR sorted them.

[mr_d_p_gumby]

Another item for Mike. I forgot to say that there is a question concerning [SetupCodes] and the DevCodesOffset entry of the [General] section that needs a mention. If DevCodesOffset is <> 0 then the values in the [SetupCodes] section are the internal setup codes, not the codes as displayed on the remote and in the DeviceButtons panel of IR.

Noted; good point.

[mathdon]

8910, 9910, HPPro have a way to display device name on the LCD screen.
RDF for CPT0CPTx1 entry is
DeviceSetup=MISC/1107,ModeName and the protocol is ModeName=01F8.
When I downloaded from 8910, on the SP sheet Type said "unknown".
When I loaded last configuration file, it also said "unknown".
When I add new custom name keymove, it stays on the SP sheet, and also says "unknown".
In IR7 it used to say "ModeName".

There's something very odd happening here. The DeviceSetup entry you mention is in the [Extender] section. This section isn't read by IR. The RDF Spec says it is used only by the Extender Code Calc spreadsheet. I've checked back to the IR 7.15 source code and it isn't read by that, either. So it is only the entry

Code: Select all

[SpecialProtocols]
ModeName=01F8

that is relevant. If I load the RDF you mention, with IR8 RC3, and look at the Type list on the Special Protocols tab, I see an SP called ModeName, exactly as I would expect.

You wrote earlier

If download a file with TV/1103 (DSM device), delete TV/1103, all DSM keymoves migrate to keymoves. If now add, on the SP sheet, a new DSM, it gets built and migrates over to keymoves. No problem for me, but might scare some people (I just built it and it ain't there).

I think I've sorted that one. I couldn't exactly reproduce it but I found a similar behaviour and have corrected it. The code was doing all the right things but, in certain circumstances, in the wrong order. Give RC4 a go and see if it is OK in that.

It's possible, though I think it unlikely, that it will also resolve the ModeName issue. If it doesn't, could you post a screenshot and say exactly what you did to create it? Thanks.

I'll deal with the width issue also in RC4.
_____________________

Graham

[mathdon]

IR 8.00 Release Candidate 4 posted

RC4 (IR 8.00 Build 14) is here. It's got a new KM icon - hope you like it. It has fixed a bug in the handling of the new Special Protocols syntax that Liz has identified, and has brought the effect of a SetupValidation entry with an absent [SetupCodes] section into line with Mike's RDF4 Spec. The field width for the Select Remote popup has been widened.
____________

Graham

[The Robman]

It's got a new KM icon - hope you like it.

I do, thanks.

[mathdon]

The two basic types of keymoves alowed in these remotes are:

1) 1 byte, where that byte is a button number; the remote then behaves as if that button had been pressed, using the setup code referenced in the keymove. This type of keymove always behaves the same way.

2) 2 bytes, where one or both bytes contain some sort of command data.

The 2-byte keymove has three variants:

A) ....
B) ...
C) AdvCodeFormat=HEX, AdvCodeBindFormat=LONG
Example: All JP1.2 & JP1.3 remotes
This type of remote can process either a 1-byte or 2-byte command. A 1-byte command stores the hex command in the first byte; the second byte is unused (but must be present). A 2-byte command stores the hex command values in both bytes. The remote does not do any pre-processing on the hex values; it always loads both bytes into the protocol buffer.

I can't speak for all JP1.2 & JP1.3 remotes, but this isn't quite right for the URC-7780/7781. A 1-byte AdvCode command (3-byte header, 2-byte setup code and 1 data byte) is a button code and is translated into a hex code (1 or 2 bytes) appropriately for the device concerned. A 2-byte AdvCode command (3-byte header, 2-byte setup code and 2 data bytes) is a raw hex command that is not pre-processed. Whether 1 or 2 bytes are actually sent is determined by the protocol. If 1 byte is sent then it is the first one and the 2nd byte is arbitrary. I've not changed anything about this in IR but with this set of RDF parameters it appears to interpret the data in this way and the signals sent by the remote match this. A setting of EFC gives nonsense data in IR.
_______________

Graham

[The Robman]

Graham, what you describe is also what Mike describes, I don't see the difference.

[Capn Trips]

How does one make the KM button active? Mine is greyed out and does nothing.

[ElizabethD]

RC4

DSM on 6131ext looks good to me. However, I don't recall whether the sequence matters. Perhaps Mike can remind me. All DSM keymoves now fell to the bottom of the list on SP sheet. I think it's ok, as what matters is that macros go after keymoves -- but can't remember

8910ext ModeName, aka Custom name ... there was a story where I think CapnTrips wanted to be able in ECC to type in a string, and ECC translated. And then RDFs were changed. For the life of me, I can't recall the details.
In anycase, it still shows unknown in download, in Add, and in loading of the IR configuration file - picture here
https://www.hifi-remote.com/forums/dload ... le_id=6584
Would you like me to post what i download from 8910 or the IR file?

Edit: Remote selection box size is now wonderful. THANK YOU.

I hope Rob gives you a raise for all this wonderful work right, Rob?

[mathdon]

Graham, what you describe is also what Mike describes, I don't see the difference.

Sorry, Mike and Rob, I was misunderstanding what you, Mike, had written. I was getting confused between your 1-byte keymoves (which are button values) and your 1-byte commands (which are straight hex and represented as a 2-byte keymove). I hadn't noticed that your A, B and C options all referred only to 2-byte keymoves. I now think we are in complete agreement.

How does one make the KM button active? Mine is greyed out and does nothing.

If you open KM outside of IR, then when you next open IR the KM button should be coloured, and active. If not, use regedit to check that there is a Registry key

[HKEY_CURRENT_USER\Software\VB and VBA Program Settings\keymap-master\KM]

IR checks for this key. The KM button is greyed out if it is not present. If you use KM but this key is absent then Mike or someone will need to help, as my understanding is that KM creates it automatically.

Would you like me to post what i download from 8910 or the IR file?

Both would be very helpful, as I think I need to be able to reproduce the problem in order to diagnose it.
__________________

Graham