Defining LKPs in RMDU Files

[Kruskal]

When necessary, Remote Master handles adding key moves to an upgrade file nicely. Is there any similar way to add LKPs to an upgrade file?

Currently, I just put a note next to each function definition saying which LKP I expect it to be and assign that function to a phantom key. Then I have to add the LKP manually in IR after I copy over the upgrade. It would be nice to be able to keep the entire thing in one place.

Thanks -- Vincent

[Mark Pierson]

I don't know about RM, but in KM you can use direct hex entry on the Functions sheet to create just about any command you want, but they'll always be cryptic jumbles of bytes that are difficult to maintain and understand. The built-in mechanisms for the special protocols in IR makes the job infinitely easier IMHO.

[Kruskal]

I don't know about RM, but in KM you can use direct hex entry on the Functions sheet to create just about any command you want, but they'll always be cryptic jumbles of bytes that are difficult to maintain and understand. The built-in mechanisms for the special protocols in IR makes the job infinitely easier IMHO.

That was the answer I expected -- and dreaded. I could code the LKPs in hex, but that IR extension interface sure is nice (and quite a surprise after reading the README).

So what do people actually do when uploading RMDU files for others to use?

Thanks -- Vincent

[Mark Pierson]

So what do people actually do when uploading RMDU files for others to use?

The upgrade files (for either KM or RM) are used to supply all the known functions for the given device along with the necessary protocol details. While the button assginments and remotes are generally user-specific, another user can take any JP1 upgrade and customize it for his/her individual preferences. It also helps not having to "reinvent the wheel". You can think of an upgrade file as another form of an Avanced Code listing.

[Kruskal]

So what do people actually do when uploading RMDU files for others to use?

The upgrade files (for either KM or RM) are used to supply all the known functions for the given device along with the necessary protocol details. While the button assginments and remotes are generally user-specific, another user can take any JP1 upgrade and customize it for his/her individual preferences. It also helps not having to "reinvent the wheel". You can think of an upgrade file as another form of an Avanced Code listing.

True. I was hoping to express fully my personal preference while recognizing that anyone who wanted to could ignore that and treat my RMDU file as an advanced code listing.

Thanks -- Vincent

[ElizabethD]

I don't know about RM, but in KM you can use direct hex entry on the Functions sheet to create just about any command you want, but they'll always be cryptic jumbles of bytes that are difficult to maintain and understand. The built-in mechanisms for the special protocols in IR makes the job infinitely easier IMHO.

Can you actually put button numbers in KM or RM? I never tried it. Just seems not practical.

Currently, I just put a note next to each function definition saying which LKP I expect it to be and assign that function to a phantom key. Then I have to add the LKP manually in IR after I copy over the upgrade. It would be nice to be able to keep the entire thing in one place.

IR is the place.

So what do people actually do when uploading RMDU files for others to use?

Mark answered. I'll just add to it.
Upgrades usually do not include keymoves to devices outside the upgrade for one unique piece of equipment, except for external functions using related setup codes to support the box you're making an upgrade for, and no other.

Another thing to consider, besides the lovely IR's UI is the purpose and ultimate use, in my opinion. System keymoves, the ones addressing all gear, belong in IR and can't be shared.

Stated a different way: Unless you just want to use LKP for two related functions within the upgrade you're constructing (short stop/long stop type of thing) you will be coding 13 step macros in LKP. That usually refers to system stuff, all other gear YOU have, making it quite user-specific and difficult to share except for educational purposes.
In contrast, the upgrades made in RM or KM can be shared because they are gear-specific.

I hope this helps a bit.

[Kruskal]

Upgrades usually do not include keymoves to devices outside the upgrade for one unique piece of equipment, except for external functions using related setup codes to support the box you're making an upgrade for, and no other.

Another thing to consider, besides the lovely IR's UI is the purpose and ultimate use, in my opinion. System keymoves, the ones addressing all gear, belong in IR and can't be shared.

Stated a different way: Unless you just want to use LKP for two related functions within the upgrade you're constructing (short stop/long stop type of thing) you will be coding 13 step macros in LKP. That usually refers to system stuff, all other gear YOU have, making it quite user-specific and difficult to share except for educational purposes.
In contrast, the upgrades made in RM or KM can be shared because they are gear-specific.

I hope this helps a bit.

I understand what you are saying. But all the LKPs which I wanted to be in the RMDU file were to permit what you called "related functions" to be on the same key. The remote just doesn't have enough buttons and, often, the best label applies to two functions. They are all of the form of a short press shifting the key and a long press doing a phantom key.

Given that RM doesn't have this LKP/DKP feature, perhaps the best way to express my device design is to have the secondary feature on a key assigned to the key, shifted. But that would mean that the RMDU file which I want to publish would be different than the one I want to use. Also, this presupposes that I didn't design shifted keys for some third purpose, a presumption which happens to be true in my case.

I guess, in an ideal world, I would want LKP and DKP to be treated as Modes in the Layout page along with Normal, Shift and XShift. But that, I think, would involve a different kind of extension which would have LKP/DKP key moves as well as LKP/DKP macros. I don't see how my use of the phantom buttons could be handled under the covers.

Thanks -- Vincent

Vincent

[Capn Trips]

If you are simply trying to show, for example, that your personal preference is to have a short press of "Stop" stop the VCR, and a long press of "Stop" eject the cassette (an LKP I personally use), I assign the "short" function to the button directly, and the "long" function to the x-shifted button (which is, after all, just a fancy way of giving a name to an otherwise "phantom" button). I do this IN THE RM UPGRADE.

Then I build the LKP on "VCR/Stop" in IR as follows:

Short=shift-Stop (uses shift-cloaking to access the "underlying" Stop function);
Long= x-shift-Stop (executes "eject")

or, to put it more generically, in RM:
Assign "short" functions to the primary button, and
assign "Long" functions to the x-shifted version of that button.

Put a note in the upgrade "notes" section stating this is how you structure the LKP function "partnerships" in IR, i.e. wherever you have an "x-shifted" button assigned as a keymove, you access it via an LKP.

Meanwhile, you have the two functions you want "sharing" one button clearly assigned to that precise button in your RM upgrade.

Of course, you still have to BUILD the LKP in IR, but the relationship between the two functions you describe is shown and explained in your upgrade file with a SINGLE NOTE, rather a bunch of notes trying to connect various phantom button assignments with various other function assignnments as "partnered" via LKP.

Another example where I have used this technique is with a CD changer, where number function "X" is assigned to the corresponding basic number button, and the "disc X" function is assigned to the "x-shifted" number button. Then the LKPs are trivial to build in IR, as the "special relationship" between the two functions associated to one button is already predefined in the imported RM upgrade.

Of course, this presumes you're using the extender. Otherwise, the "x-shifted" column of buttons won't appear in RM

But since this post is in the "extender" section, and MOST LKP protocols are designed to work only with extenders, I think I'm on safe ground here assuming that. 8)

P.S. Before the advent of RM, in which you can predefine keymoves to "x-shifted" buttons, I did this in KM, but had to use only "shifted" rather than "x-shifted" buttons, so that created an extra hassle in IR where I had to take every imported "shifted" keymove from the KM upgrade that I wanted to do this on, and edit it in IR to be an "x-shifted" keymove.

[gfb107]

See the thread Using LKP instead of shift.

[Kruskal]

See the thread Using LKP instead of shift.

That's right on point. Thanks.

But it looks like it never made it into a 8811 extender.

Vincent

[Kruskal]

If you are simply trying to show, for example, that your personal preference is to have a short press of "Stop" stop the VCR, and a long press of "Stop" eject the cassette (an LKP I personally use), I assign the "short" function to the button directly, and the "long" function to the x-shifted button (which is, after all, just a fancy way of giving a name to an otherwise "phantom" button). I do this IN THE RM UPGRADE.

Then I build the LKP on "VCR/Stop" in IR as follows:

Short=shift-Stop (uses shift-cloaking to access the "underlying" Stop function);
Long= x-shift-Stop (executes "eject")

or, to put it more generically, in RM:
Assign "short" functions to the primary button, and
assign "Long" functions to the x-shifted version of that button.

Put a note in the upgrade "notes" section stating this is how you structure the LKP function "partnerships" in IR, i.e. wherever you have an "x-shifted" button assigned as a keymove, you access it via an LKP.

Meanwhile, you have the two functions you want "sharing" one button clearly assigned to that precise button in your RM upgrade.

Of course, you still have to BUILD the LKP in IR, but the relationship between the two functions you describe is shown and explained in your upgrade file with a SINGLE NOTE, rather a bunch of notes trying to connect various phantom button assignments with various other function assignnments as "partnered" via LKP.

Another example where I have used this technique is with a CD changer, where number function "X" is assigned to the corresponding basic number button, and the "disc X" function is assigned to the "x-shifted" number button. Then the LKPs are trivial to build in IR, as the "special relationship" between the two functions associated to one button is already predefined in the imported RM upgrade.

Of course, this presumes you're using the extender. Otherwise, the "x-shifted" column of buttons won't appear in RM

But since this post is in the "extender" section, and MOST LKP protocols are designed to work only with extenders, I think I'm on safe ground here assuming that. 8)

P.S. Before the advent of RM, in which you can predefine keymoves to "x-shifted" buttons, I did this in KM, but had to use only "shifted" rather than "x-shifted" buttons, so that created an extra hassle in IR where I had to take every imported "shifted" keymove from the KM upgrade that I wanted to do this on, and edit it in IR to be an "x-shifted" keymove.

Given the current state of RM/IR/Extenders, I think you have hit upon the best solution to my desires. But RM has the XShift button grayed out for me. How do I tell it that I intend to use an extender so I can do what you suggest?

Stop for Eject -- I like that, never occurred to me. I'd like to see a collection of mnemonic mappings of functions to button names such as that as a source of ideas. I even would contribute some. Is there such a collection? If not, where could such a collection be started? A sticky thread?

Thanks -- Vincent

[Mark Pierson]

But RM has the XShift button grayed out for me. How do I tell it that I intend to use an extender so I can do what you suggest?

Select the proper extended remote (URC-8810x x2 or URC-881x x3 where x2/x3 indicate the extender version).

[Kruskal]

But RM has the XShift button grayed out for me. How do I tell it that I intend to use an extender so I can do what you suggest?

Select the proper extended remote (URC-8810x x2 or URC-881x x3 where x2/x3 indicate the extender version).

Get it. Much to learn.

But I have the choices 881x, 881x 1k, 881x x3 2k and so forth. Am I to assume that 881x is really 881x 2k? What is an 881x 1k?

Thanks -- Vincent

[Capn Trips]

You need to look at the extender that you're using in your IR file. In the top Window title bar of IR, it usually says what rdf file you're using. I would imagine you're using the latest 2K extender - at least that's what I'd recommend.

I'm not an 8811 guy, but I'd recommend reading the readme's for each extender to determine if it applies to you (1K, 2K, etc) first - I'd wager you have a 2K EEPROM, and then, if there are more than one that apply, read some more to determine which one has the features you seek. Normally, you'd end up using the most recent extender, as NORMALLY, they are updated to fix bugs, BUT that's not always the case - check the features and choose the one you want. Then you have to make sure you select the same rdf for each of your upgrades and for IR.

But as Mark said, in RM, if you select an Extender rdf, then the xshift buttons become active.

[Kruskal]

You need to look at the extender that you're using in your IR file. In the top Window title bar of IR, it usually says what rdf file you're using. I would imagine you're using the latest 2K extender - at least that's what I'd recommend.

I'm not an 8811 guy, but I'd recommend reading the readme's for each extender to determine if it applies to you (1K, 2K, etc) first - I'd wager you have a 2K EEPROM, and then, if there are more than one that apply, read some more to determine which one has the features you seek. Normally, you'd end up using the most recent extender, as NORMALLY, they are updated to fix bugs, BUT that's not always the case - check the features and choose the one you want. Then you have to make sure you select the same rdf for each of your upgrades and for IR.

But as Mark said, in RM, if you select an Extender rdf, then the xshift buttons become active.

I'm not having a practical problem -- it was pretty clear that I wanted to use 881x x3 2k since I would have noticed if I had done something to get a 881x x3 8k.

However, I was confused about the naming of the other 881x's. I gather that the 881x usually comes with 2k and that 881x really means 881x 2k. Also, where do the 881x 1k come from? Half the memory and no extenders available!

Thanks -- Vincent