My offer to make enhancements in IR

[e34m5]

I am a big jp1 user/fan and also a Delphi developer. After corresponding with Nils he suggested that I post my offer to help make enhancements to IR.

So, please make your requests, I will socialize them with the jp1 "tribal council" and then make enhancements as time permits.

Thank you for allowing me to give back to this group. If you have any questions please do not hesitate to ask.

[johann83]

I think the only request I ever had for IR was the ability to be able to add comments to things like keymoves and macros. Sometimes after I go back to my config months later, I have a hard time remembering what each keymove/macro does. At one point I ended up with a seperate spread sheet which had comments for each item, but I kept forgetting to update it. So now I usually just go back and re-"figure out" what each item is for.

Seems to me that it would be pretty easy to add a "comment" column to the UI, but I'm not sure how you would save them. Right now the save files only contain the raw EEPROM data (which IR properly formats based on the RDF), so adding text comments to that format may be problematic. I still think it might be a worthwhile item to pursue.

Matt

[e34m5]

Hmm..at one time I had the same thought..I think I'll try that..perhaps the comments can be saved on a separate file and then merged for display purposes.

[johnsfine]

IR internally manages data structures representing the meaningful structures of configuration (the collection of KeyMoves, for example). But it only stores the raw eeprom image.

A whole lot of different IR feature requests depend on the change to instead load and store both the raw data version and the meaningful version of the same configuration.

If you want to tackle that large change, I suggest you first collect together several of the different reasons for making that change, so as to design a new file format that supports those features.

I also suggest that files of the new format begin with a section identical to the old format (a hex eeprom image) and we define a simple rule for recognising the end of that portion, so another program (or intermediate version of IR) can use just the eeprom image by knowing where to stop reading.

Two important feature requests depending on a new format are:
1) A way for IR to know device specific function names, especially for KeyMoves, but maybe even for upgrades. We would also need to enhance the copy/paste interface from RM and/or KM to IR so that those function names could be passed. I'm not sure if that covers Matt's request for comments or whether comments go beyond the device specific function names (in KM and RM they do).
2) Remember which KeyMoves were installed as part of a device upgrade (rather than added by IR's UI) because those KeyMoves should be removed if that upgrade is removed or replaced.

[Mark Pierson]

Using an .ini-like file format might be the way to go. The current hex data can remain as is and notes can be stored in additional named sections following it. Then all IR has to do is look for these sections.

[e34m5]

Ok I had to open my big mouth . I will be reviewing all the code in IR so as to get my head around what is there. So far I am very impressed with the way it has been coded.

I like your idea John of creating multiple sections in the file. One with the hex definition as is today and another with any extra information.

As I dive deeper I am sure I will have more questions.

[johnsfine]

An often requested feature that doesn't need a new file format is:

Support the typical extender DSM and ToadTog protocols on IR's Macros tab. DSM's are clearly much easier (for IR) and more important than ToadTogs, so maybe just do DSMs.

1) You need a way for the extender RDF to tell IR about the DSM protocol.

2) You need a little extra GUI on the macros tab to support selection of the DSM feature.

3) We want the same GUI for defining the body of a DSM that we have for defining the body of a macro (that's the whole reason we want this new IR feature).

4) IR already understands the similarities of macros to keymoves and how to load both into the same eeprom area. The changes should be minor to support DSMs, which are internally KeyMoves but should look to the user like macros.

5) To avoid confusion, we probably should add the minor change to always put KeyMoves (including DSMs) into the eeprom image before macros.

[e34m5]

Ok. I see what you mean. Perhaps a check box similar to the shift check box but labeled DSM. Then when you build the macro it automatically uses that protocol.

I like that idea.

[johnsfine]

Ok. I see what you mean. Perhaps a check box similar to the shift check box but labeled DSM.

I think it would make more sense as a "device mode" pull down, with the top choice being "all" indicating that the macro is really a macro and the other choices being the (up to eight) device modes that support KeyMoves, indicating both that a DSM is requested and which device mode it should be in.

[The Robman]

I would like to have the ability to "edit" learned signals, in much the same way that we can edit device upgrades, for example. Currently, when you click on the EDIT button, the pop up panel only lets you change the button that the signal is assigned to, I would like the panel to also display the raw data in a window where you can cut & paste it. This would let people cut & paste learned signals from one remote to another.

I would also like to have the ability to define multiple non-contiguous upgrade sections in a remote's RDF. This would allow us to let the upgrade section overflow into the learning memory if we want. I believe it would also help with extenders, as it would let the pre-extender load avoid the couple of bytes used at the start of the learning section.

I would like to see an RDF Builder Wizard added to IR (which would not be a small undertaking). When IR detects that there's no RDF for the remote that was just downloaded, it would examine the memory format and make some pre-liminary assumptions (like whether the processor is S3C8, 740 or 6805 based), it would then ask the user some questions, like "how many device buttons does this remote have?". This would help the user build a "starter" RDF, though we'd still need manual input from an expert to finish it.

I'd like to have an option where you can edit the signature in the remote. This would be an option from the Advanced menu which would invoke a small pop-up where the signature is shown in ASCII format (rather than hex format).

For example, the sig for the 15-1994 is "RSL6RSL0", but if you look at the raw data you will just see "52 53 4C 36 52 53 4C 30". To convert the hex to ASCII you need to look it up on a chart, which is a drag. I'd like to be able to click on something and see the sig displayed in an editable field in ASCII format.

It would be nice to have the second part of the signature for 6805 remotes included, which is currently just defined as fixed data.

For 740 remotes (ie, the Producer and Topline series), it would be nice if you could define the various memory sections from IR, rather than having them hardcoded into the RDFs. Then when you download the memory from one of these remotes, IR would look for the memory definitions, which are present in the EEPROM, rather than looking for them in the RDFs.

I would like to be able to expand the concept of "fixed data". Currently, when you define fixed data, IR expects the data to already be set to those values before the download and it even uses the fixed data to decide which RDF to use when they are similar. I'd like to be able to have IR always set certain bytes to a pre-defined value, regardless of what value was in those bytes when the memory was downloaded. This will be useful for certain 6805 remotes which have "anti piracy" bytes that keep track of how many times you have changed the setup codes assigned to the device buttons and if you exceed a certain limit, the remote will scramble the EFCs on the keypad.

Something similar would also be useful for remotes that use the same signature, like the various Cat48 remotes. We could define something in the RDF which would change the last digit of the signature, so when the user initially downloads from their remote, they will have to select which RDF to use, then once the RDF is selected, IR will change the signature slightly so that the next time the data is downloaded from the remote, the correct RDF will automatically be selected.

[johnsfine]

I would like to have the ability to "edit" learned signals, in much the same way that we can edit device upgrades, for example. Currently, when you click on the EDIT button, the pop up panel only lets you change the button that the signal is assigned to, I would like the panel to also display the raw data in a window where you can cut & paste it. This would let people cut & paste learned signals from one remote to another.

If the only intent there is to Copy/Paste whole learned signals, I think it would be better to make THAT the feature. Showing the raw data in the GUI will just confuse people.

Have COPY and PASTE commands somewhere (preferably buttons in the learned signals GUI, but EDIT menu pull down or right click are almost as good). COPY should copy the raw hex (that the user can't see) to the clipboard and PASTE should check the clipboard for compatible raw hex and paste it if so. Advanced users who want to mess with the raw hex could use COPY, then paste to Notepad, then do whatever, copy from notepad and PASTE to IR.

[johnsfine]

Another desired change on the learned signals tab is to hide all that timing data (sent once, etc.).

By default, when you click on a learned signal you should just get the decodes.

There should be an option stored somewhere (I don't remember where IR stores other options) to turn on the "advanced" display for learned signals, which would put it back the way it is now.

The extra info on that page may be the number one cause of beginner confusion, so beginners shouldn't see it at all.

[johnsfine]

I would also like to have the ability to define multiple non-contiguous upgrade sections in a remote's RDF. This would allow us to let the upgrade section overflow into the learning memory if we want.

I've responded to this one in detail in past discussions. If you consider adding this feature, please look at my previous discussion of it.

In summary, making IR understand that upgrades can overflow into other unfilled areas would be both easier and more useful than having the RDF specify the extra upgrade areas.

[johnsfine]

I would like to be able to expand the concept of "fixed data". Currently, when you define fixed data, IR expects the data to already be set to those values before the download and it even uses the fixed data to decide which RDF to use when they are similar. I'd like to be able to have IR always set certain bytes to a pre-defined value, regardless of what value was in those bytes when the memory was downloaded. This will be useful for certain 6805 remotes which have "anti piracy" bytes.

I like that idea, and several S3C80 remotes (such as 15-2104) also have anti-piracy bytes that need this.

To clarify, you're asking for a kind of "fixed data" that IR will silently fix whenever it's wrong and will not use in resolving ambiguous RDF choices and will not ask the user whether to fix.

You still want to keep ordinary "fixed data" behaving the way it does now. You want some syntax in the RDF to distinguish one kind of fixed data from the other. The simplest syntax would be a second RDF section with a different name than "fixed data" with the same internal syntax as fixed data.

[e34m5]

OK..slow down ...how about you guys prioritize the requests and we'll work them one at a time..