JP1 Remotes

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.

Going from memory when I worked on IR5 I am pretty sure it will require changes in IR.

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.

Oh yeah, shift-cloaking, I remember that. I can never remember when to use it and when no to use it. That'll definetly help on the keymove space.

Nils have you given any thought to how you want to handle xshift?

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.

Well, you said that when the "Auto LKP" feature is enabled, standard shift would no longer work. So how would the user trigger xShift?

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.

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

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.

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.

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.

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.

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

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

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.