View previous topic :: View next topic |
Author |
Message |
Nils_Ekberg Expert
Joined: 02 Aug 2003 Posts: 1689 Location: Near Albany, NY |
Posted: Thu Jan 27, 2005 11:12 am Post subject: |
|
|
This may not be too difficult to program so I will dig into it.
In the interim you can save some bytes by assigning the short button code to the real base button in RM, the long on the xShifted button in RM or IR, and then the LKP on the base button in IR. This way you only end up with 1 keymove for the xshifted and the LKP itself.
The LKP would then be set up as: Short = shift-button - Long = xShifted-button.
What happens is when you execute the short shifted-button and nothing is there it automaticly executes the code on the base button ignoring the fact that the LKP is also on it. It's that shift cloaking thing. _________________ Nils
Files Section
Diagnosis File Section |
|
Back to top |
|
|
e34m5
Joined: 14 Oct 2003 Posts: 675 Location: Atlanta |
Posted: Thu Jan 27, 2005 11:16 am Post subject: |
|
|
Going from memory when I worked on IR5 I am pretty sure it will require changes in IR. _________________ Paul |
|
Back to top |
|
|
Nils_Ekberg Expert
Joined: 02 Aug 2003 Posts: 1689 Location: Near Albany, NY |
Posted: Thu Jan 27, 2005 11:30 am Post subject: |
|
|
e34m5 wrote: | Going from memory when I worked on IR5 I am pretty sure it will require changes in IR. |
The way I am currently thinking this it would all be in the extender with an option in the RDF the that would show up in the other settings on the main tab of IR like VPT, Alternate shift etc..
Basically, if the LKP shift is turned on I would set the shift flag in the remote and send the shifted button to the remote. If the option is off then I would send the base function to the remote. And, if there is no shifted function assigned it would send the base function.
This is over simplified but in the end it just creates two ways to manually send a shifted function. Either by first pressing the shift button then the real button or by holding the button down. If the option is OFF then the only way to send a shifted function manually is by pressing the shift button first. If it is ON then the only way to manually send a shifted function is by holding the button down. _________________ Nils
Files Section
Diagnosis File Section |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
Nils_Ekberg Expert
Joined: 02 Aug 2003 Posts: 1689 Location: Near Albany, NY |
Posted: Fri Jan 28, 2005 8:26 am Post subject: |
|
|
gfb107 wrote: | Nils have you given any thought to how you want to handle xshift? |
Not really. I assume what you mean though is how do we handle the alternate shift function. _________________ Nils
Files Section
Diagnosis File Section |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
Nils_Ekberg Expert
Joined: 02 Aug 2003 Posts: 1689 Location: Near Albany, NY |
Posted: Fri Jan 28, 2005 9:23 am Post subject: |
|
|
I have to think this out a little but within most extenders you can tell if it is the Xshift so it may not be a problem. It may be as simple as if "auto shift" is on and shift is used it must be Xshift but until I dig deeper I am not sure how to implement. _________________ Nils
Files Section
Diagnosis File Section |
|
Back to top |
|
|
mtakahar Expert
Joined: 03 Aug 2003 Posts: 281
|
Posted: Sat Jan 29, 2005 1:11 am Post subject: |
|
|
gfb107 wrote: | I understand that not everyone would want it to be global.
Those of us who want it globally would install the extender that implements this. |
I guess that's all depends on the types of devices you have and your remote controlling habits. The delay necessary for handling LKP may be frustrating if you have a button somewhat timing sensitive.
For example in my case, I like FFx3 + overshooting correction rather than 30 sec skip. Here I prefer if the button press sends the signal immediately when I press the FF key. I once tried putting an LKP that does a FF on the short side and FFx3 on the long side, but I didnt' like it because of this very slight delay.
Well, it may be just matter of getting used to it, or Nils may be able to overcome this issue. I don't know.
For those who want to enable this behavior only on the specified buttons in specific device modes, I think it's fairly easy to create a special protocol like:
(1) You put a key move with the device associated with this new special protocol, without specifying any arguments.
(2) Define the shift (or xshift) function on it.
(3) It sends the signal defined on the unshifted button on the short press and the shifted one on the long press.
This should save both the programming effort and the key move space a little bit, not as much as the embedded solution, but this is more flexible.
Hal |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Sat Jan 29, 2005 8:59 am Post subject: |
|
|
mtakahar wrote: | I guess that's all depends on the types of devices you have and your remote controlling habits. The delay necessary for handling LKP may be frustrating if you have a button somewhat timing sensitive. |
I agree. I hoped that it would check to see if something is defined on the shifted button first. If there isn't, just process the button. If there is, start the logic associated with determing if an LKP is occurring.
Quote: |
For those who want to enable this behavior only on the specified buttons in specific device modes, I think it's fairly easy to create a special protocol like:
(1) You put a key move with the device associated with this new special protocol, without specifying any arguments.
(2) Define the shift (or xshift) function on it.
(3) It sends the signal defined on the unshifted button on the short press and the shifted one on the long press.
This should save both the programming effort and the key move space a little bit, not as much as the embedded solution, but this is more flexible.
| So the protocol could figure out without any parameters the original device type of the button? That's cool.
If it really is a lot easier to code, and it really is a matter of creating just one additional parameterless keymove on the desired button, I'd be willing to try your suggestion. _________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
Nils_Ekberg Expert
Joined: 02 Aug 2003 Posts: 1689 Location: Near Albany, NY |
Posted: Sat Jan 29, 2005 9:51 am Post subject: |
|
|
I got the embedded to work (occasionally) on the 9960 but I didn't like the ever so slight delay plus I did not get rid of the conflict with the regular LKP yet. I know I can write a special LKP that uses no parms so let me play with that.
I think making it button selective is a better solution and still quicker to use then a regular shift. _________________ Nils
Files Section
Diagnosis File Section |
|
Back to top |
|
|
e34m5
Joined: 14 Oct 2003 Posts: 675 Location: Atlanta |
Posted: Sat Jan 29, 2005 10:10 am Post subject: |
|
|
Is still think it is easier to add a check box when using the SP tab.
The check box would say Auto-LKP. It very easy to determine the default assigment of a button. Then all the user needs to do is define the Long portion.
This could also be done on KM/RM like it happens today. _________________ Paul |
|
Back to top |
|
|
Nils_Ekberg Expert
Joined: 02 Aug 2003 Posts: 1689 Location: Near Albany, NY |
Posted: Mon Feb 07, 2005 12:59 pm Post subject: |
|
|
Greg
Try this in your 6131 and see if it works. It expects one parm of zero for now. I have not tested this version yet since I am in work but from a desktop review it should work.
Set your base button and the shifted button. Create a keymove for this device upgrade to the same button with a hex value of zero.
If this works I can make that one value the timeout values or just default it to a short timeout.
By the way, normal shift will still work on buttons that don't have this keymove on it.
It is set for a very short timeout so just tap the button you assign it to
and it should send the base button. Hold it and it should send the shifted button
URC-6131
Code: | Upgrade code 0 = 1C 54 (TV/1108)
FF 00 01
End
Upgrade protocol 0 = 01 FF (S3C8+)
00 00 03 FF 00 01 00 00 01 E4 03 4A F0 4A
56 4A 0F F6 1F 80 F6 13 EE FB 08 76 6B 20
6B F6 46 4C 80 AF
End |
_________________ Nils
Files Section
Diagnosis File Section
Last edited by Nils_Ekberg on Tue Feb 08, 2005 11:17 am; edited 1 time in total |
|
Back to top |
|
|
Nils_Ekberg Expert
Joined: 02 Aug 2003 Posts: 1689 Location: Near Albany, NY |
Posted: Tue Feb 08, 2005 11:12 am Post subject: |
|
|
Greg,
If the first test did not work try adding a parm of 1 or 2 and try it again.
If that one did not work try this one but include a parm for it also like 1 or 2 for a short duration
Code: | Upgrade protocol 0 = 01 FF (S3C8+)
00 00 03 FF 00 01 00 00 01 E4 03 4A F0 4A
56 4A 0F F6 1F 80 87 43 2D 82 7F C4 F6 13
EE FB 08 76 6B 20 6B F6 46 4C 80 AF
End |
_________________ Nils
Files Section
Diagnosis File Section |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Wed Feb 09, 2005 11:24 am Post subject: |
|
|
Nils, I couldn't get either upgrade to work. Neither the short nor the long press send the desired signals.
Here's what I did:- Install protocol upgrade
- Install device upgrade
- Define keymove on DVD/Stop using setup code TV/1108 and HEX cmd $02
- Define keymove on DVD/shift-Stop using builtin setup code DVD/0539 with EFC 32 (Eject)
Using traditional shift-Stop still works.
I should mention that I am using the 6131 extender, and I have not unistalled the LKP protocol that is included with the extender. _________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
|