JP1 Remotes

Found an interesting bit of behavior when trying to do a keymove to a shifted key using the 2116ext2 extender. Took me a while to figure out what was happening, but after I stripped out the extender and set the code on a non-extended remote, I figured out my problem.

After re-reading the readme.txt for the extender, I guess this was implied there, but I've reached a new level of understanding on how a keymove works in the context of a button group, especially when extenders are involved.

Setup:
I use the extender macros in a basic VPT mode so that the volume keys are assigned to a my receiver. (i.e. TV button macro does a SET_VOL_KEYS on the Audio device, then sets everything else to the TV device)

Problem:
If I try to assign a keymove to the TV: SHIFT-MUTE button, I cannot actually use that key from the TV device. In this case I wanted to use the shifted mute key to send the mute command to my TV, which turns on the closed captioning. TV speaker is turned off (all audio goes through the receiver), so MUTE basically equals "CC Toggle".

Turns out, since the Volume keys (Mute included) are actually set to the Audio device (at the register level), then the shift version of those keys are also on the Audio device.

So in order to be able to use a SHIFT-MUTE keymove for the TV device, I need to assign it to AUDIO:SHIFT-MUTE (or whatever device the Volume keys have been assigned to.)

Its an obvious difference once you think about how the extender works, but its different from my past experience using a more conventional "VPT" behavior on my 1994. In this case (at least as far as I can recall) the TV: SHIFT-MUTE key still "belongs" to the TV group.

So I guess this is just an informational post for anyone using an extender having problems doing keymove and having problems with codes not working on shifted buttons. Remember that shifted buttons get "punched through" too!

EDIT: Bloody Typos!

I'm sorry you were confused.

When I started handling Key Groups in extenders, I went to quite a lot of extra trouble to create that particular behavior. I didn't write this particular extender, but I'm the source of that design decision.

My number one reason for that design decision is I always put Eject on shift-Stop and I have multiple VCRs and use dynamic HT (transport punch thru) for VCRs, so in TV or CBL mode the remote remembers which VCR was most recently selected. I needed the shifted keys to be in the group with unshifted keys or shift-stop wouldn't work.

It certainly is different from the way either dynamic transport punch thru (the urc-7800 has it) or the HT transport group work on unextended remotes. But that's the point of an extender, to change the things we think the un extended remote got wrong.

Yeah, its cool now that I understand it. In fact I'm sure I can make more use of it now that I understand the behavior.

It mostly sort of an "ahaa" type thing when I realized that setting a keygroup to a certain device REALLY means setting it to that device.

The arbitrary assignment of any keygroup to any "device" is totally cool, it just requires that the user get his (my) head unstuck from the traditional "Device" model.