Phantom Device assignment on 8910/9910/HTPro

[Capn Trips]

Question: If I have more than eight devices I want to use, I understand that I can have additional upgrades installed and NOT assigned to device buttons and make Keymoves from them, butt there are a few behaviours in IR that puzzle me.

(1) When uploading a device upgrade with included Keymoves, IR always prompts me to assign it to a Device Button, "or else" the Keymoves will be lost, or won't work, or something like that. I thought that it was immaterial whether or not one assigns an upgrade to a device button. Is the warning in IR correct? ...or a relic of some previous behaviour in the past? Regardless, if I don't assign it to a device button, those Keymoves will not be imported, - why not?

(2) So, I've installed this upgrade, and assigned it device "db-08". After saving this file, when I re-open it, these keymoves are suddenly assigned to the TV device button - how come?!?
Is this behaviour unique to the 8910 family? Does it apply to all phantom device buttons?

(3) Alternate Scenario: I install the upgrade, and assign it to a device button (db-08 ) temporarily - to permit import of the Keymoves. I then immediately de-assign that device upgrade from the device button. The Keymoves now have an <N/A> in the Device Button column. Does this mean the Keymove ought not work?

Just seeking a greater undstanding of the workings of IR.

[Mark Pierson]

(1) why not?

IR needs to know where to bind the key moves. The embedded key move format that comes over from KM/RM is "generic" so IR must decide (or ask) where they belong. The only way it can do that is by forcing device button assignment.

Somewhere on the wish list is the ability to let IR create the unbound key moves so that the user can easily set them up in the future.

(3) The Keymoves now have an <N/A> in the Device Button column. Does this mean the Keymove ought not work?

No... it just means the key move isn't using a setup code assigned to a device button.

[The Robman]

Like Mark said, when you create the keymoves in KM or RM, you haven't yet selected which device button they belong to, so you need to do so when you copy them over, and the way IR handles it is to assign the upgrade to a device button, but you're free to remove it from the device button after the fact.

Please ignore the fact that the db-xx buckets are there as they are NOT real device modes, you certainly can't assign keymoves to those modes.

Keymoves are a good idea for programming devices like video selectors, where you only use the device to help you watch other devices, but if you have more than 8 real devices, you should be looking at using the device multiplexor to stack several devices onto a single device button.

[johnsfine]

I think you're confusing the two sides of a KeyMove.

The source side of a KeyMove is a setup code and a hex command. That setup code does NOT need to be assigned to a device button, and IR does NOT ask you to.

The target side of a KeyMove is a "bound" device mode and "bound" key. There must be a bound device mode for IR to store the KeyMove.
In an upgrade from KM or RM, there is no bound device for the KeyMoves. The upgrade itself represents the bound device. But when you install it, that upgrade must be assigned to a device button for the KeyMoves to work.

Question: If I have more than eight devices I want to use, I understand that I can have additional upgrades installed and NOT assigned to device buttons and make Keymoves from them

The key is KeyMoves FROM them. When you install such an upgrade it must not include any KeyMoves TO the upgrade.

(1) When uploading a device upgrade with included Keymoves, IR always prompts me to assign it to a Device Button,

Those are KeyMoves TO the upgrade, so a device button is required.

Is the warning in IR correct?

Yes.

(2) So, I've installed this upgrade, and assigned it device "db-08". After saving this file, when I re-open it, these keymoves are suddenly assigned to the TV device button - how come?!?

Most JP1 remotes have an internal data structure design that allows more than eight device buttons but only eight indexes for binding KeyMoves to device buttons. So any KeyMove bound to either device 0 or device 8 will be available in either of those device modes and displayed by IR in device 0. So your KeyMoves were assigned to both TV and db-08. Similar pairing for 1-9, 2-10, etc. up to however many real plus phantom device keys the remote has.

The JP1.2 remotes fix that flaw.

Does it apply to all phantom device buttons?

It applies to all device buttons after the first eight. In a model with fewer than eight real device buttons, it doesn't apply to all the phantoms. In a model with more than eight real device buttons they must have fixed this flaw.

(3) Alternate Scenario: I install the upgrade, and assign it to a device button (db-08 ) temporarily - to permit import of the Keymoves. I then immediately de-assign that device upgrade from the device button. The Keymoves now have an <N/A> in the Device Button column. Does this mean the Keymove ought not work?

If I understand you correctly, the original KeyMoves were both TO and FROM the upgrade. You need a device button for them to be TO. When you selected one, they were both TO and FROM a device button. When you deassigned the device button, the side effect of where they were TO was left, but the device button they were FROM was gone.

Being FROM a device button is totally optional. The KeyMove is really FROM a setup code. That device button is just displayed to remind you which device button has that setup code, if there is one.

[Capn Trips]

Thanks all. Got it.

I won't claim to "understand" but I see what the limitations and restrictions are.

You see, I have usually used the technique of importing a bunch of functions that I want to be keymoves from KM or RM as part of that upgrade, and then after they're in IR, I'd go to the Keymove sheet and modify them to get them assigned to the device index and button I wanted.

I've not done this before, but I presume if I built External Keymoves in KM/RM (i.e. assigning functions from my device upgrade to ANOTHER Device index), then these would not have any problem with being imported even if I did not assign the upgrade I'm importing to a device index.

[Capn Trips]

I think you're confusing the two sides of a KeyMove.

You're right. Once I think about it in those distinct terms, it makes sense.

I will point out, however, that the Keymove display in IR contributes slightly to this confusion, as there are TWO columns labeled "Device Button".

As I now comprehend, that FIRST "Device Button" column MUST have a REAL Device index selected, otherwise the Keymove is meaningless, whilst the SECOND "Device Button" column is just there as a visual aid, letting you know that the setup code from which that keymove is generated happens to be (or not, in the case of <N/A>) assigned to a device index (real or phantom)

[The Robman]

I suppose that a logical enhancement to this message in IR would be that if you select that you do not want to assign the device upgrade to a physical device button, it should then ask you if you would like to assign JUST the keymoves to a physical device button.

It might be worth taking a small step back and try to get a broader understanding of what things like keymoves really are. If you think about how you program a keymove on the remote itself, you need to explicitly tell the remote where to store the keymove (ie, which device button is it stored under). You either do this by default when you select the device mode before you program the keymove, or you do it explicitly when you copy a button (or EFC) from one mode to another. Either way, the keymove has to end up somewhere. You also have to tell it which setup code to use, again either by default when you select a device button (and therefore a setup code) before you program the keymove, or explicitly when you copy a button from one mode to another.

Also, once a keymove is programmed, it will remain in place even if you then chose to change the setup code programmed to the device button that you used when you programmed the keymove.

In an un-extended remote, the db-xx buckets serve no purpose whatsoever. There aren't any db-xx device buttons (phantom or real) so you can't select those device modes, therefore if you were able to program a keymove to those modes, you would have no way of actually using the keymove.

If you're not already familiar with how to program keymoves using IR.exe (rather than KM/RM) you might want to take a look at it. In some cases it might be easier to just program the keymove that you need using IR rather than trying to set it up in KM/RM and then import it.

[johnsfine]

In some cases it might be easier to just program the keymove that you need using IR rather than trying to set it up in KM/RM and then import it.

In lots of cases keymoves from a different setup code are easier to program in IR than in KM/RM.

But I think you should select the method based on what leaves the most understandable trail in your created files and is easiest to edit/maintain later.

As we enhance IR, (or build a Java replacement) I think we should give it better ways to structure KeyMoves based on why they are needed.

Some major categories of WHY are:

1) Ordinary functions consistent with the other ordinary functions of an upgrade, BUT you happen to want them assigned to keys that aren't in the map for that device type. Letting RM/KM tell IR is clearly a step up from having the user program these KeyMoves in IR.

2) Functions of the same oem device as an upgrade but with a protocol/device/subdevice combination that doesn't fit. These clearly belong in the external functions definition of the upgrade they are KeyMoved into, NOT in the helper upgrade they may be keymoved from, NOR done manually in IR.

3) Unstructured cross device keymoves. You want to have a few functions of one device available in the mode of another. These are best done in IR, because it represents the way you use your system, rather than aspects of either individual device.

4) Structured cross device keymoves (input select and if anything else acts a lot like input select). You want the definition of your preamp to inject its TV input select into some key in TV mode and inject its CD select into the same key of CD mode, etc. These represents aspects of that preamp, not of the other devices or the combined system. So you'd rather have these define in the preamp's upgrade as KeyMoves FROM that upgrade (as distinct from case 2, which is KeyMoves TO the upgrade). Note these KeyMoves are TO specific modes.

5) Minimal device: You have a device with just a few keys and instead of giving it its own device key, you want to let it share a device mode with some upgrade that had a few keys to spare. This seems to be the case Capn Trips wanted and it doesn't fit the existing concepts of the KM->IR interface. You want the keymoves defined in the upgrade for the mini device (not as external functions in the upgrade for the device it will share with, nor manually in IR). They are KeyMoves FROM the upgrade being defined, but unlike (1) they are not TO that same upgrade, and unlike (4) they are not TO specific targeted upgrades. They are TO unknown device mode to be selected in IR.

Rob's suggestion lets the user in IR/KM could treat case (5) sort of like case (1) and then give IR a way to treat it differently as it gets installed.