My offer to make enhancements in IR

[johnsfine]

I though you'd want to look at them and pick the one you're most comfortable with. But if we want priorities, my vote is

1) GUI for DSM
2) Upgrades overflow into the unused ends of other areas.
3) Hide learned signal timing data from beginners
4) Support extra data after raw eeprom image in file format
5) Remember which KeyMoves were installed with upgrades (requires 4)
6) Have function names for KeyMoves (requires 4)
7) Two kinds of fixed data
8) TOADTOG support similar to (1)
9) COPY/PASTE learned signals
10) Device/Model name for setup code (requires 4)

Maybe it's because I only half understand Rob's signature and RDF requests, but I haven't included them in my top 10. I also didn't include my own earlier "function names in upgrades" idea. If I were to go beyond top 10, I'd bring in a bunch of others not mentioned yet rather than those. I'm sure Rob and others will have very different lists. I hope in my top 10 I've at least given a concise but specific description suitable for priority list discussion.

[e34m5]

I think I'll tackle #1 first. This will give me chance to become more familiar with the code and also seems it's probably the oen where I can do the least damage at first

Question: I haven't had a need for DSM so I'm not familiar but is the same protocol used for extender vs non-extender.

[johnsfine]

I split off the technical details of the DSM GUI to another thread
http://www.hifi-remote.com/forums/viewtopic.php?p=9537
so people can post any opinions on the other parts of this thread here without digging through DSM GUI details.

[The Robman]

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.

I don't think it will be any more or less confusing than letting them see the raw data for upgrades and protocols, both of which are available right now. Plus, by making the raw data visable and editable, experts can "play" with it if they like.

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

I would certainly like to add my vote for this idea.

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.

For the anti-piracy bytes, I want IR to silently update the fields, as you suggest, without bothering the user for input on the process.

For things like when multiple remotes share the same signature, I would define the RDFs using just the first 7 bytes of the sig (instead of the full 8 bytes). Then when the right RDF is selected, I would change the 8th sig byte to a value of my chosing. Then when data is next downloaded from this remote, IR would use that 8th byte to identify which RDF to use.

If I do this now and define the 8th byte as fixed data, IR would complain that there is a fixed data conflict, etc...

[mr_d_p_gumby]

Another small item to add to the list: a KeymoveSupport= option in the RDF. This would work just like the MacroSupport option, only it would hide the Key moves tab for those remotes that do not support keymoves.

Another item: a MultiMacroType=?? RDF option that would tell IR how to handle the multi-macro control bytes. UEI has used several different methods for this, and IR currently only knows how to handle it for the newer versions.

For the anti-piracy bytes, I want IR to silently update the fields, as you suggest, without bothering the user for input on the process.
...
If I do this now and define the 8th byte as fixed data, IR would complain that there is a fixed data conflict, etc...

It would be nice to have the "silent fixed data" and still have IR be able to distinguish the second signature from the anti-piracy fixed bytes, for example. Maybe the second signature needs it's own section or entry.

[Oinge]

Having just upgrade my 8810w to the extender 3.1 and using a lot of keymoves and macros. I recall thinking many times working through small problems that it would be nice to be able to sort the key moves and macros by device code. As a novice user I know this would have been helpful to debugging the macros and keymoves. Having no real experience programming, I don't know if this is a simple or difficult request.

[The Robman]

In order to try and keep this thread somewhat on topic (for Paul's benefit), I have split off the discussion of extenders and overflows, etc into this thread...

IR enhancements - overflow area discussion