JP1 Remotes

The absolute easiest thing would be perhaps emulate the file format like this

Upgrade Code 0 = 25 C4 (VCR/1476) GI Cable 0476
C4 08 72 FE 7C 61 B0 70 F0 D0 30 50 C8 98 0C 2C
AC 6C EC 88 CC 1C 9C 5C DC 48 A8
KeyMoves
2A F3 25 C4 1C 2B F3 25 C4 9C 2C F3 25 C4 5C 2D
F3 25 C4 DC
Notes
BoundKey:BoundDevice {Day UP} BoundKey:BoundDevice {Day DOWN} BoundKey:BoundDevice {Page UP} BoundKey:BoundDevice {Page DOWN}
End

This then becomes very easy to read in and load into memory because it follows the same pattern established in IR.

What about the Upgrade Notes??

(BTW, tx for the reply)

e34m5 wrote:The absolute easiest thing would be perhaps emulate the file format like this
Notes
BoundKey:BoundDevice {Day UP} BoundKey:BoundDevice {Day DOWN} BoundKey:BoundDevice {Page UP} BoundKey:BoundDevice {Page DOWN}
End

The problem is that neither KM nor RM know which device the keymoves are going to be bound to. That occurs solely in IR and is at the user's discretion.

What about the Upgrade Notes??

What about them?

e34m5 wrote:]The absolute easiest thing would be perhaps emulate the file format like this
Notes
BoundKey:BoundDevice {Day UP} BoundKey:BoundDevice {Day DOWN} BoundKey:BoundDevice {Page UP} BoundKey:BoundDevice {Page DOWN}
End
The problem is that neither KM nor RM know which device the keymoves are going to be bound to. That occurs solely in IR and is at the user's discretion.

Huh..All the ones I pasted in already had the keymoves bound. With out this info how do you associate a note to the keymove then.

What about the Upgrade Notes??
What about them?

Are we going with the format ou suggested for the Upgrade Notes.

e34m5 wrote: Huh..All the ones I pasted in already had the keymoves bound. With out this info how do you associate a note to the keymove then.

The usual way for a KeyMove to accompany an upgrade requires the KeyMove to be bound to whatever device key will be given the setup code of the upgrade.

KM/RM can't know which device key that is, so the KeyMoves are passed in a device-key-generic form. When IR receives the upgrade and KeyMoves together, it can figure out the decive kery and/or ask the user.

Maybe what we really want is the ability to bind a KeyMove to an upgrade INSTEAD of to a device key.

Then IR wouldn't need to ask the device key when you paste the upgrade and an KeyMoves.

When you assign an upgrade setup code to a device key, IR could create the internal (bound to that device key) version of any KeyMove that exists in external form bound to that upgrade.

Agreed..as I mentioned before KM notes with out BoundDevice and BoundKey are out of context.

IR cannot discern what KM to associate the note with out this info.

Maybe I don't understand something but in the KM tab of KeyMaster it clearly asks for those two elements. In my mind creating a KM in KeyMaster associated with a device other than the one the upgrade is for seems counter intuitive since there may not be a device setup selected in IR for the other device. Sure IR asks this when you paste but you may not know this at the moment

e34m5 wrote:IR cannot discern what KM to associate the note with out this info.

Maybe not, but there can only be one key move for any given BoundDevice:BoundKey combination.

Maybe I don't understand something but in the KM tab of KeyMaster it clearly asks for those two elements. In my mind creating a KM in KeyMaster associated with a device other than the one the upgrade is for seems counter intuitive since there may not be a device setup selected in IR for the other device. Sure IR asks this when you paste but you may not know this at the moment

KM can create TWO types of key moves. The first is what I call "Combined Key Moves" (and are the same ones RM creates). These are defined on the Buttons sheet by assigning functions to any buttons that are NOT part of the default key map. When pasted into IR, they get bound to the same device as the upgrade code. The code for these is copied and pasted at the same time as the Device Upgrade Code.

The second type of key move gets created on the Key Moves sheet. There you can take functions from the CURRENT upgrade and assign them to OTHER devices (audio input selections, for example). KM does "bind" them to a device index. As far as I know, IR does NOT prompt the user for anything when importing these key moves (using the [Import] button on the Key Moves tab). The code for these is copied from the Key Move Code block on the Setup sheet.

Maybe not, but there can only be one key move for any given BoundDevice:BoundKey combination.

Exactly. No probelm there

KM can create TWO types of key moves. The first is what I call "Combined Key Moves" (and are the same ones RM creates). These are defined on the Buttons sheet by assigning functions to any buttons that are NOT part of the default key map. When pasted into IR, they get bound to the same device as the upgrade code. The code for these is copied and pasted at the same time as the Device Upgrade Code.

No prob. This results in a unique combination then

The second type of key move gets created on the Key Moves sheet. There you can take functions from the CURRENT upgrade and assign them to OTHER devices (audio input selections, for example). KM does "bind" them to a device index. As far as I know, IR does NOT prompt the user for anything when importing these key moves (using the [Import] button on the Key Moves tab). The code for these is copied from the Key Move Code block on the Setup sheet.

Again.. No prob. This results in a unique combination then

Based on the above thenit seems to me that you could write out notes as I described earlier. It doesn't matter whether it's a "combined key move" or one created in the KM tab.

Again, I may be misunderstanding some thing here. Bear with me if I am.

e34m5 wrote:Based on the above thenit seems to me that you could write out notes as I described earlier.

Unfortunately, KM doesn't have a complete list of all the "official" button names available (remember, it doesn't use the RDF's the way RM and IR do). The best I can do is supply the button code and hope IR can do the rest.

That shouldn't be a problem because IR is obviously processing the information already, since it can take the key move hex and display it with the proper BoundDevice:BoundKey in the Key Moves grid.

e34m5 wrote:Are we going with the format ou suggested for the Upgrade Notes.

I'm happy with appending the note after the "(<DevType>/<SetupCode>)" in the Device Upgrade Code and the "(<ProcessorType>)" in the Protocol Code:

Upgrade Code 0 = 34 61 (CD/1121) Aiwa NSX-D23 CD Stereo System

Upgrade Protocol 0 = 00 5E (S3C8+) Aiwa

Ok....let's try DeviceCode:KeyCode

Where DeviceCode = 1 to 7 and KeyCode is ButtonCode...IR can decipher it from there.

The other notes are great as you described. Go ahead and make up a couple of examples and I'll use them for development.

Tx.

e34m5 wrote:Ok....let's try DeviceCode:KeyCode

Where DeviceCode = 1 to 7 and KeyCode is ButtonCode...IR can decipher it from there.

By DeviceCode, do you mean the Device Type as referenced by the Setup Code in the device upgrade (i.e. VCR/1234)? If so, you should already have that from parsing the upgrade code, because IR is populating the Device Type drop-down as soon as the code is pasted in. If you're asking for the DeviceIndex that represents "VCR" in this example, KM doesn't know it as I explained above.

Mark:

I'm not trying to belabor the point. This is from your e-mail

24 = button code
F4 = F = bind it to the upgrade device
4 = 4 bytes follow
26 23 = dev index 2, setup code 623 (1571)
D4 00 = 2-byte hex command

So what we need is (2) for dev index and (24) for button code.

So that the notes for KeyMoves would be like this:

KeyMoves
2A F3 25 C4 1C 2B F3 25 C4 9C 2C F3 25 C4 5C 2D
F3 25 C4 DC
End

02:24{NOTE} etc....

I think you're misunderstanding the relationship between the device type of an upgrade and the device mode that the upgrade will be assigned to. Effectively there is no relationship.

The 02 in the above example is the device type of the upgrade. It is not appropriate to use it in specifying the keymove for notes (or other purposes).

The F in the above example is a stand in for the device mode. If KM knew the device mode it would be used instead of that F. F is used to indicate KM doesn't know the device mode.

If the KeyMove is referred to outside that KeyMoves block, it should be identified by the keycode together with either an F or the device mode (whichever KM knows).

Ok I guess I don't.

When I paste this in IR

KeyMoves
2A F3 25 C4 1C 2B F3 25 C4 9C 2C F3 25 C4 5C 2D
F3 25 C4 DC
End


I get this

15 RCVR F.REW <N/A> Audio 1476 $1C
16 RCVR F.FWD <N/A> Audio 1476 $9C
17 RCVR M1 <N/A> Audio 1476 $5C
18 RCVR M2 <N/A> Audio 1476 $DC

So clearly the BoundDevice is RCVR and BoundKey is F.REW etc...so why can't we just have that same realtiosnship in KM for the notes. Obviously KM knew how to build that.

I'm not trying to be obtuse but something is clearly eluding me here.