| View previous topic :: View next topic |
| Author |
Message |
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
 Posted: Thu Feb 05, 2004 2:05 pm Post subject: |
 |
|
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. |
|
| Back to top |
|
 |
e34m5
Joined: 14 Oct 2003
Posts: 675
Location: Atlanta
|
| Posted: Thu Feb 05, 2004 2:08 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
johnsfine
Site Admin
Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA
|
| Posted: Thu Feb 05, 2004 3:07 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Thu Feb 05, 2004 3:22 pm Post subject: |
|
|
| johnsfine wrote: | | 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.
| johnsfine wrote: | | 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.
| johnsfine wrote: | 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...
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
mr_d_p_gumby
Expert
Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA
|
| Posted: Thu Feb 05, 2004 9:30 pm Post subject: |
|
|
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.
| The Robman wrote: | 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.
_________________
Mike England |
|
| Back to top |
|
|
Oinge
Joined: 19 Sep 2003
Posts: 34
|
| Posted: Thu Feb 05, 2004 10:04 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Fri Feb 06, 2004 4:52 pm Post subject: |
|
|
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
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
