Seeking suggestions for enhancements for IR.exe

Post by **mathdon** » Fri Jan 16, 2009 5:17 pm

I'm still rather confused as to what is being asked for regarding Device Multiplexor. It seems to be a suggestion that you could reference 'fictitious' devices in a key move or macro and get IR to translate that, in what it puts into EEPROM, into a macro using Device Multiplexor that performs the requested operation. The 'fictitious' device would then not exist outside IR, in contrast to a phantom device that is encoded into the extender, but it would achieve the same effect.

Am I right? This would require an algorithm to convert everything that can be done with a phantom device into something done without phantom devices. This might be possible, but at present I can't see how. I think that given enough phantom keys (not phantom devices) one can do everything without a phantom device that can be done with one (I switch the effect of long key presses - LKP protocol - in my Zone1/Zone2 switching for the Onkyo TX-SR606) but I can't see how one could do it with an algorithm.

Post by **vickyg2003** » Fri Jan 16, 2009 5:37 pm

The Device Multiplexor work around is NOT something for IR. It requires changing the way the remote works. This would be extender functionality, not IR functionality

Post by **vickyg2003** » Sun Jan 18, 2009 12:33 pm

I have a question about how IR determines the Special Protocols Sheet. I'd like to be able to have more than one ToadTog protocol for my remotes. I have the register availability, but don't know if I could have two toad tog constructors. With 10 device remotes, it would be nice to have a toggle bit available for every byte. I've got the bits, just don't know how to accomplish this in IR.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Sun Jan 18, 2009 1:18 pm

vickyg2003 wrote:I'd like to be able to have more than one ToadTog protocol for my remotes.

I think IR would almost do this now. The way this works is that the RDF enables the special protocol with an entry like

Code: Select all

[SpecialProtocols]
ToadTog=0181

IR looks for the presence of an upgrade protocol with the PID specified in the RDF. It then searches the device upgrades until it finds one that uses the specified PID. If all of this is satisfied, then it is activated on the special protocol tab. What is needed is some optional way to give the special protocol a different name.

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:

Code: Select all

[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.

mr_d_p_gumby · Post by **mr_d_p_gumby** » Sun Jan 18, 2009 1:50 pm

While we are on the subject of special protocol handling in IR, there is one other modification that would be useful. As I mentioned above, the RDF enables the SP in the [Special Protocols] section like this:

Code: Select all

[SpecialProtocols]
LDKP=01F9
ToadTog=0181
Pause=01FB
DSM=01FC
Multiplex=01FE

This is fine for most cases, but causes a problem with the URC-6131 & Atlas (SA_7) extenders, where Hal devised a very efficient way to embed the DSM code directly into the extender, so there is no protocol upgrade present. To get the DSM activated within IR, users must temporarily load a dummy protocol upgrade, which can be problematic since most of these remotes only have a 1K EEPROM and space is very tight.

I would like to propose that IR accept an alternate syntax in the [Special Protocols] entries:

Code: Select all

[SpecialProtocols]
LDKP=01F9
ToadTog=0181
Pause=01FB
DSM=-01FC
Multiplex=01FE

Here, the DSM entry has a negative PID argument. IR would recognize this, and skip over the test for presence of a protocol upgrade. Other processing would remain the same, i.e., the device upgrades would still be searched for one that uses PID 01FC.

Post by **vickyg2003** » Mon Jan 19, 2009 1:14 pm

Something else I'd really like to see is the Processor listed somewhere. Maybe on the RAW Data Page. I know for most of you this isn't an issue, you just pop open the RDF and read it. For me however, with my short attention span combined with with dyslexia, finding the right RDF to look at is an arduous task.

unclemiltie · Post by **unclemiltie** » Mon Jan 19, 2009 2:37 pm

I thought of another one today

It would be really cool if in IR I could apply a "keyname" to a key and then use that key in the list of commands in a macro.

For example, on my Yamaha receiver, I have Phantom1 (a key) set to be the discrete input on the receiver for the DVD player. Then I use X_AUD,Phantom1 to select the DVD input.

With lots of these, it gets confusing so if I could define the keymove for Phantom 1 that also includes a "keyname" I could then define Phantom1 as "InputDVD" my macros would be much easier to understand.

If there is no "keyname" then IR could use the regular old key. If there is one, then it would substitute. Same goes for Macros. Even though it's bound to a key if it had a name like "All-on" when I used it somewhere I could see what it was doing.

(there will likely be some issues that have to be thought through in the user interaction and how these are displayed, but having this would be neat)

Post by **mathdon** » Tue Jan 20, 2009 11:12 am

Apart from the need for a lot of further testing, I've completed what I wanted to do to make IR work well with URC-7780/81 (and potentially any future remotes that use 'soft' device selection via an LCD).

I've added a display of the Processor to the RAW Data Page, as Vicky suggests - as that is the easiest of the suggestions that have been made! I've also done another easy one that I picked up here. I'll post further messages as I explore/implement other suggestions.

Post by **vickyg2003** » Tue Jan 20, 2009 2:17 pm

Thanks Mathdon. Being able to see the processor information is a great help to me personally.

Mark Pierson · Post by **Mark Pierson** » Tue Jan 20, 2009 4:23 pm

mathdon wrote:I've also done another easy one that I picked up here.

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?

Post by **mathdon** » Wed Jan 21, 2009 9:10 am

A question to Mike England: If I delete protocol 01FC from my extender and try to set up a DSM in the Special Protocols tab, all that goes wrong is that when I press OK, I get asked "This function will not work correctly until you load the associated Special Protocol (01FC). OK/Cancel?" If you press OK, then the entry is correctly made in the RAW data and presumably would work correctly in the remote. I can't see the need to install a dummy protocol. If you just want me to get rid of this message if the protocol is entered as negative in the RDF, then I can easily do so. Or is there something more about this that I am missing?

A question to Vicky: Would your intention be to create an extender that had two ToadTogs built in, each with a protocol that uses its own byte of RAM for the ToadTog flags? I'll look into the naming issue but I would also like to understand quite how you intended to get the second ToadTog into the extender, if it was other than by building it into the extender code.

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.

Post by **vickyg2003** » Wed Jan 21, 2009 9:31 am

A question to Vicky: Would your intention be to create an extender that had two ToadTogs built in, each with a protocol that uses its own byte of RAM for the ToadTog flags? I'll look into the naming issue but I would also like to understand quite how you intended to get the second ToadTog into the extender, if it was other than by building it into the extender code.

Yes I was thinking about just adding a second ToadTog construct, but working outside the box, perhaps I could do something more creative. 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.

Post by **ElizabethD** » Wed Jan 21, 2009 11:04 am

mathdon wrote:A question to Mike England: If I delete protocol 01FC from my extender and try to set up a DSM in the Special Protocols tab, all that goes wrong is that when I press OK, I get asked "This function will not work correctly until you load the associated Special Protocol (01FC). OK/Cancel?" If you press OK, then the entry is correctly made in the RAW data and presumably would work correctly in the remote. I can't see the need to install a dummy protocol. If you just want me to get rid of this message if the protocol is entered as negative in the RDF, then I can easily do so. Or is there something more about this that I am missing?

Hi!
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

Post by **mathdon** » Wed Jan 21, 2009 12:57 pm

Thanks, ElizabethD. So it's the device upgrade, not the protocol upgrade that is absent from the extender. I take it from the quote you provided that the entry for the EEPROM buffer should be exactly the same as if there was a device upgrade for TV/1103 that used protocol 01FC. I could implement this, triggered by a minus sign before the protocol ID, by providing a default device type and code for each of the protocol IDs normally used for special protocols. IR would then only object if there were neither an upgrade device nor a default device associated with the protocol.

I've already implemented most of this to see how it would work, so if I've understood correctly what is wanted, just say so and I will do it. It does make more sense than the protocol upgrade being absent, as if that were absent I couldn't see how the code could be called.

Post by **ElizabethD** » Wed Jan 21, 2009 1:08 pm

Yes, you got it (to the extent that I got it:))
Seriously, it is DEVICE upgrade.
Incidentally if device upgrade is already in the existing file, then ???

Is this thread for serious changes to IR, or can we toss some editing suggestions for ease of maintenance? I don't want to muddy up and haven't yet read the whole thread carefully. Is IR being totally rewritten or something?