JP1 Remotes

R2-M0 · Joined: 14 Aug 2009 Posts: 92

As this is the first time I've ever worked with an LKP-enabled extender, I have what may be a newbie-ish question.

I've set up my device keys as LKPs, with a short press executing XShift-device (which performs the normal device select macro sequence) and a long press executing Shift-device (which performs the turn-everything-on-and-select-the-right-inputs macro). That all works a treat.

Here comes the part I'm unsure about, tho. I've had to duplicate each LKP button definition on every device. In other words, I have the same CBL LKP defined on the CBL button in the TV device + AUD device + DVD device + CBL device, so that the LKP will be recognized no matter what mode I'm in when I push the CBL button.

Is there a cleaner way to do this with without duplicating all those LKP setups?

mdavej · Expert Joined: 08 Oct 2003 Posts: 4501

Yes there is. Anything on the Macro tab is a global macro, meaning it will execute in every device mode. So put one CBL macro on the Macro tab that calls your LKP.

R2-M0 · Joined: 14 Aug 2009 Posts: 92

Perfect, thanks! I hadn't figured that the special nature of an LKP would still be in effect when called from a macro like that.

ElizabethD · Advanced Member Joined: 09 Feb 2004 Posts: 2348

R2-M0,
Just to elaborate what mdavej said - my take on this:
Basically, for most of the stuff, a common macro can be used. No duplication of LKP.
But watch out for the "which device are we in now" issue.
The way I handle is via common, global macro, something like this
AUD macro= phantomX
Then every device calls this macro using Dev_AUD after the one keysets macro is used. Something like this:
TV macro= Dev_AUD,Set_Vol,Dev_TV, phantom9, Dev_AUD,phantomX
where phantom9 sets a bunch of keys I want for all devices (you can just use the set, set, set jobs as well here)

Then in AUD/PhantomX: LKP on the short side I just do Dev_Cancel nothing. Keysets are ready from the calling macro, nothing more to do.
On the long side, Dev_Cancel is followed by are the keymoves or whatevers that belong to the calling device - usually synchronizing inputs.

The reason for Dev_Cancel is I don't want to end up controlling AUD device. I want to control TV or CBL or DVD or ...
When the AUD LKP job ends, on either side, I'm, still controlling TV, or whatever called the LKP in the first place.
The only time Dev_Cancel not needed is for the AUD device itself.

I do it like this in 8910, 6131, C7, Atlas, and looks like it works here as well.

I've heard conflicting opinions about Dev_Cancel, as in 'you never need it'. But I use it because it works for me.

EDIT:Please ignore all my writing about the need for Dev_Cancel. It's not correct.
EDIT#2: : After a bit of discussion, the sort of setup I use does require Dev_Cancel, but not on the short side of LKP. You can see detail in several posts below.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile

jimdunn · Joined: 29 Jun 2004 Posts: 544 Location: NSW, Australia

R2-M0 · Joined: 14 Aug 2009 Posts: 92

Thanks, Liz! Even though I didn't end up doing quite the same thing you did, your suggestions led me to a cleaner and less convoluted solution for my device macros.

Originally, I had (for each DEVice)...

an XShift-DEV macro that performed the normal device selection sequence,
a Shift-DEV macro that performed the system config (discrete power ups, input settings, etc),
a Phantom1 LKP for each device that called XShift-DEV on a short press, Shift-DEV on a long, and
a DEV macro that did a Dev_DEV,Phantom1 (so that I only had to define the LKP once but could still have it work across all devices)

After reading about your setup, though, I was able to streamline that down to...

a DEV macro that performs the normal device selection sequence, then calls Phantom1,
a Phantom1 LKP for each device that does nothing on a short press, but Shift-DEV on a long, and
my original Shift-DEV macro to perform the system config

Much simpler. And yes, I know that I could just embed the contents of the Shift-DEV macro into the "long" portion of the Phantom1 LKP to streamline a little bit more. But this way, I can perform system set up with either Long-DEV or Shift-DEV. And since I got used to Shift-DEV before I had the extender, I figure that'll be handy while I retrain my thumb Wink

So my newly extended remote now includes pauses, LKPs, ToadTogs, a DSM, Shifts and XShifts... And it's all working beautifully. Thanks a million, unclemiltie!

mdavej · Expert Joined: 08 Oct 2003 Posts: 4501

That's the same way I do it too. But Liz gave me another idea. I now have one macro that sets all dev key groups that I call first, then set just the exceptions. So CBL, for example has Dev_CBL then calls the macro to set all 6 key groups, then I do a Dev_TV Set_Vol. This makes all my DEV macros a lot shorter since they can all call the same master key group macro.

Extender is looking great here too. I have more tests planned for all phantoms and every toadtog bit.

One nitpicky suggestion I have would be to arrange the Buttons section in the order they are on the remote so I don't have to hunt for functions, i.e., move Mute closer to the Vol keys, etc.

jimdunn · Joined: 29 Jun 2004 Posts: 544 Location: NSW, Australia

R2-M0 · Joined: 14 Aug 2009 Posts: 92

Ah, the joys of JP1 tweaking. I also ended up adding a Phantom2 macro like Liz's last night.

I realized that, while my Shift-DEV macro was properly configuring all my hardware just like a Long-DEV press, it wasn't leaving the remote in the proper state to control the selected DEVice. So I set up Phantom2 as "Set_Trans, Set_Chan, Set_Menu, Set_Other" and changed Short-DEV to call Phantom2. Long-DEV still just calls Shift-DEV, but I added Phantom2 to the end of Shift-DEV so the key groups are properly set no matter what. Problem solved.

I just use the General tab to permanently set the Vol group to AUD and the PIP group to dev6 (so I can control my pedestal fan no matter what mode I'm in).

And since we worked out the issues with the original RDF, I've yet to encounter any other problems with the extender. I've also taken advantage of Xshift-cloaking too, so there's one more feature confirmed to be working as advertised.

At this point, I think I have the RCRP05B pretty much exactly where I want it to be. At least until I come up with something else cool I can squeeze out of it... Smile