Page 45 of 59
Posted: Wed Aug 24, 2011 10:47 am
by vickyg2003
The Robman wrote:vickyg2003 wrote:Is that how RM handles a variant for a remote that has a variant already built in?
yes, to see an example, select remote 15-1994 and then select the "Pioneer MIX" protocol ($007E). MIX is a variant of DVD (DVD is the version that's built into the 15-1994), so when you select MIX you get an upgrade with pid $017F. Now, change the remote to 15-2116 and the protocol upgrade goes away and the pid is $007E once again. Now change the protocol to DVD and you'll get an upgrade with pid $017E.
I see that this is how both RM and KM work. This AlternatePID method seems to only have been implemented on three of the protocols that have variant information. The rest ask for user supplied pids in KM.
Was the AlternatePID method abandoned? Or is there something really special about these protocols?
Posted: Wed Aug 24, 2011 11:02 am
by The Robman
IIRC, it was invented for this protocol. The problem is that from UEI's POV, it's a single executor that they keep improving. However, from our POV, each version of the executor has its own merits, so we gave them different names. And, we could envision situations where a user might want to use both variants.
For example, let's say the user has the 15-1994 remote and already has an upgrade loaded for a Pioneer DVD that is using the built-in $007E "Pioneer DVD" protocol. Now, let's say that they buy a new Pioneer TV that requires the "Pioneer MIX" version of $007E. If we let them install that version of $007E as an upgrade, it will break their DVD upgrade, so we use a different pid.
Likewise, let's say the user has the 15-2116 remote and already has an upgrade loaded for a Pioneer TV that is using the built-in $007E "Pioneer MIX" protocol. Now, let's say that they buy a new Pioneer DVD that requires the "Pioneer DVD" version of $007E. If we let them install that version of $007E as an upgrade, it will break their TV upgrade, so we use a different pid. In this case, a better idea might be for them to use the DVD2 option which will format an upgrade using the built-in executor.
Posted: Wed Aug 24, 2011 3:13 pm
by gfb107
The Robman wrote:OK, slightly different topic (and this one might be for Greg). On the Functions tab in RM, I think it would be a good idea to have the Primacy thing be a button at the bottom which toggles between OBC and Hex. It might also be cool to have a blob appear in the column heading of the selected option. I think Vicky uses this feature the most, so maybe she could weigh in on this idea.
Looking into this. My first thought is to put the choice on the Setup tab, either between the Protocol and Protocol ID or after the Protocol ID (before the Protocol Parameters). The reason to put it on the Setup tab is because that is where you change the protocol, and you are trying to influence what happens when you do that.
I think I agree that primacy should not be saved between runs. I would also consider an option for controlling whether or not the primacy selector is shown on the setup tab.
Oh yeah, one more thing. Currently, if you want to delete a function from an upgrade, you first have to go to the Buttons tab and find all the buttons that it might be assigned to, delete them, and then return to the Functions tab to delete it. Would it be possible to just let the user delete the function and have RM automatically delete any button assignments? That would really reduce the amount of clicking required to delete a function.
OK, I can do that. Do you think a confirmation dialog is appropriate when the function being deleted is currently assigned to one or more buttons, or would that be overkill?
Posted: Wed Aug 24, 2011 5:09 pm
by The Robman
gfb107 wrote:OK, I can do that. Do you think a confirmation dialog is appropriate when the function being deleted is currently assigned to one or more buttons, or would that be overkill?
Overkill. If you don't want the function, you don't care if it's assigned to a button or not.
Posted: Sat Aug 27, 2011 11:29 am
by mathdon
The Robman wrote:1) I think the "Hide Upper" button might be better labeled "Expand" and then "Collapse". I didn't know what it meant until I tried it.
2) In "New Manual Protocol" mode, I clicked on "Import Protocol Upgrade" and nothing happened, so I guessed that this was one of those "put it in the clipboard first" buttons, so I cut&pasted a protocol and it worked. As I mentioned to Greg before on some of the other import type buttons in RM, I don't think this style of UI in very intuitive, I think it would be better to give the user a UI to paste the code into. Greg re-used the "Import Raw Upgrade" panel in other places and I think that would be a good idea here too.
3) Could I suggest a different UI for the new "PF Details" tab. I think a UI similar to the "Protocol Data" tab would work better here, where the options are presented as drop-down menus, with the appropriate option pre-selected. I know you're hoping to truly make this an editor in the future, and I think this UI would work better with editor functionality.
4) When you enter the "Manual Settings" panel, I think it would be a good idea to have the first populated processor type pre-selected, so the additional info appears without the user first needing to click the protocol code.
This really is some great stuff that you've added, I really appreciate it.
OK, slightly different topic (and this one might be for Greg). On the Functions tab in RM, I think it would be a good idea to have the Primacy thing be a button at the bottom which toggles between OBC and Hex. It might also be cool to have a blob appear in the column heading of the selected option. I think Vicky uses this feature the most, so maybe she could weigh in on this idea.
Oh yeah, one more thing. Currently, if you want to delete a function from an upgrade, you first have to go to the Buttons tab and find all the buttons that it might be assigned to, delete them, and then return to the Functions tab to delete it. Would it be possible to just let the user delete the function and have RM automatically delete any button assignments? That would really reduce the amount of clicking required to delete a function.
I've done 1) and 3) and a variant of 4) - the code for the processor of the current remote is pre-selected, rather than just the first non-empty one. I've uploaded these to SourceForge for Greg.
Greg, I would like to leave 2) and the two separate suggestions to you. If you have time, perhaps you could do them and post Alpha 12 with them added, otherwise post Alpha 12 with just my changes (see above) or let me know and I'll post Alpha 12.
Posted: Sat Aug 27, 2011 12:36 pm
by The Robman
mathdon wrote:I've done 1) and 3) and a variant of 4) - the code for the processor of the current remote is pre-selected, rather than just the first non-empty one.
Re #4, good idea, I like it. Thanks Graham.
Posted: Wed Sep 14, 2011 4:23 pm
by vickyg2003
I'm using RM 2.02, alpha 10, and have found that importing KM Manual Settings type upgrades for the newer remotes like the 15-135 series, RCA RCR095B, and the URC-8820N series, that store the whole PID in the upgrade, instead of flagging it in the upgrade number, are importing the PID incorrectly.
So for a PID 01FF , the PID changes to 01 when you import it.
Posted: Thu Sep 15, 2011 2:41 pm
by gfb107
Vicky, please provide a sample upgrade file that exhibits this problem. I'm sure I could put one together, with some effort, but since you already have one you know causes the error it would be great if you could provide it.
Posted: Thu Sep 15, 2011 4:11 pm
by vickyg2003
Oh Sorry Greg,
The one that called the problem to my attention is this one.
http://www.hifi-remote.com/forums/dload ... le_id=9925
That one is a two byte protocol, and looses the non-OBC byte as well. Perhaps you can look at that too.
Posted: Thu Sep 15, 2011 4:25 pm
by mathdon
mathdon wrote:Greg, I would like to leave 2) and the two separate suggestions to you. If you have time, perhaps you could do them and post Alpha 12 with them added, otherwise post Alpha 12 with just my changes (see above) or let me know and I'll post Alpha 12.
Greg, that's a quote from
this earlier post of mine. I should be grateful if you have time to look at these issues of Rob's, raised some weeks ago. Don't post Alpha 12, though, as I will shortly have an assembler feature ready for testing and would like that to be in Alpha 12.
Posted: Thu Sep 15, 2011 6:10 pm
by gfb107
I'm travelling this weekend, but it looks like I might have some time to work on this stuff next week.
Posted: Sun Sep 25, 2011 2:20 pm
by vickyg2003
I ran into a simple protocol that would not dissassemble in RM
example file here.
http://www.hifi-remote.com/forums/dload ... le_id=6014
-----------------------
Request:
Could a FILE/NEW get rid of all custom protocols, so we don't have to restart RM or RMIR over again.
Posted: Mon Sep 26, 2011 4:36 am
by mathdon
I've checked this in v2.02 Alpha 11 and you are right, it doesn't disassemble in that version. It does. however, in my latest development version so I appear to have spotted the bug, whatever it was, and already fixed it. A new version, with assembler/builder facilities, will be forthcoming shortly. I'll bear in mind your request about File/New but sorting out the PB-style facilities will take precedence.
Posted: Mon Sep 26, 2011 2:24 pm
by vickyg2003
mathdon wrote:
I've checked this in v2.02 Alpha 11 and you are right, it doesn't disassemble in that version.
I'm a version behind again. You and Greg are keeping me hopping. Looking forward to version 12.
Posted: Mon Oct 03, 2011 9:10 pm
by gfb107
I've made the requested enhancements. Graham, let me know when your assembler/builder is ready for alpha (or official) release.