JP1 Remotes

DGG wrote:WOW!!!!

Your proposal certainly has "sex appeal" but, unless you plan to provide a similar graphical (layout-supported) interface for the basic button assignment functions and are simply using "keymoves" as a way to prove the concept, I'm not sure it's worth the effort (But then, it's your effort.)

Have you used the Layout panel? You can assign functions to buttons there, in a number of different ways:
- Right click on a button in the image and choose the function
- Drag a function onto a button in the image
- Click on a button to select it, then double-click on a function to assign it.

For me, the simple tabular interface you describe would suffice. Frankly, I don't see the companion layout as being particularly useful even for button assignment, and especially not for keymoves on non-"upgrade" devices, since only the buttons assigned in the current upgrade could be taken into account - at best, an incomplete picture - unless, of course, you can access IR.exe's .txt file.

The problem is that you don't know which device button the upgrade is going to be assigned to. That is done in IR.

But, let me offer a couple of specific comments anyway.

It would be possible to have no device button highlighted

I think the device button for the bound device of the keymove selected in the table should always be highlighted. I don't see any advantage to differentiating between the "upgrade" device and the others in this way.

Already addressed above.

On the right side would be a table containing the list of defined Keymoves

Would this include keymoves automatically generated by RM for, say, shifted keys? If so, they should be specially tagged. And, if they could be modified under this tab you may want to consider some form of flagging under the Buttons tab as well. Otherwise, I'd be concerned about confusion, and contention (RM's simple refusal to proceed in the face of an error condition rather than providing an error message isn't one of my favourite features) between the Keymove tab and the Button tab.

No, this would be the same list as is currently displayed in KM.

There are at least two other classes that should be considered for a comprehensive list of keymoves but that (I suspect) couldn't be accounted for on the new Keymove tab. They are keymoves generated directly with IR.exe and keymoves for the upgrade device set up on the Keymove tab of the upgrades for other devices (i.e., the function that started this discussion).

That could only be handled when RM takes over IR's functions in addition to KM's. That is the eventual goal, but is in the distant future.

Finally, RM's current External Functions cabability, while the name suggests otherwise, is just another keymove assigment mechanism, i.e., it sets up keymoves on the upgrade device that cause some other device to do something. I appreciate that the Functions/Buttons mechanism is used to make the assignment but, they are, nonetheless, keymoves and in fact, are treated that way in the output file.

True, it is, and this is why (not really understanding the purpose of KM's Key Move sheet) I didn't think I needed to implement the Key Move sheet, 'cause I thought I had it covered by External Functions. Actually, what RM does today it really conceptually "Imported Functions", meaning functions taken from other devices, and KM's "Key Move" sheet deals with "Exported Functions". The fact that they are both actually keymoves can actually cause confusion to the novice.

One of the goals of RM was to be more "user-friendly", by attempting to hide some of the complexity of JP1. One way to do that was to interact with functions in the same way regardless of whether they are assigned to keys in the button map, are for the current device but assigned outside the button map, or are for a different device altogether.

If all keymoves relevant to the "upgrade" device can't be included, I'd be inclined to re-label the function "External Keymoves" and limit it to setting up keymoves on another device that require execution by the "upgrade" device. That being said, it seems to me the new function logically could be integrated with the current External Functions tab, with the bound device (or the presence or absence thereof) defining the general nature of the keymove.

I'll have to think about that a bit.

PS: Going back to an earlier post, why does one need to specify the type of data to be entered into the External Function EFC/Hex field. Is this a shortcoming of using JAVA? Why not simply enter data in the traditional form, i.e., $xx for hex, "abc" for character strings and assume anything else is an EFC?

It's not just a matter of entering data, it also a matter of displaying the data. Remember that the data associated with a function is really just a sequence of bytes (often only one, but sometimes more). How would RM know how the user wants to view this value? I suppose I could just say, well, if it's one byte, always do EFCs. If it more than 1 byte, look at each byte and check to see if it is in the valid range for ASCII characters, if it is, display it as Text, otherwise display it as Hex. I think that is more confusing and subject to misinterpretation than having the user specify how to display the data.

gfb107 wrote:True, it is, and this is why (not really understanding the purpose of KM's Key Move sheet) I didn't think I needed to implement the Key Move sheet, 'cause I thought I had it covered by External Functions.

Actually, what RM does today it really conceptually "Imported Functions", meaning functions taken from other devices, and KM's "Key Move" sheet deals with "Exported Functions". The fact that they are both actually keymoves can actually cause confusion to the novice.

From KM's perspective, External Functions (you do realize KM supports them, right?) are functions from OTHER devices that are being added to the CURRENT upgrade. For example, you're creating an upgrade for a DVD and want to include the input select functions from your receiver. You can enter those receiver functions right on the Functions sheet and then assign them to any button on the Buttons sheet. If you're creating an upgrade for DVD/0000, you can specify External functions from, say, Amp/0000. When KM creates the key move for one of these External Functions, IR assigns it to Bound Device: <current upgrade device>, Bound Key: <selected button>, Device Type: Amp, Setup Code: 0000.

Key Moves (talking about the Key Moves sheet), on the other hand, are all based on the CURRENT upgrade. They can be bound to the current device (by selecting "(upgrade)"), or to other device types (in the Bound Device drop-down). One feature of the Key Moves sheet is that you can assign the SAME function to multiple Bound Device/Bound Key combinations if you so desire (i.e. mapping an input select function to every device button). Again, all Key Moves created in DVD/0000 use Bound Device:/Bound Key: <as selected on the Key Moves sheet>, Device Type: DVD, Setup Code: 0000.

Yes, the terminology gets confusing, but conceptually, External Functions and Key Moves are vastly different in the way they're used.

Replying to gfb107, you've caught me out. No, I've never used the Layout sheet as a substitute for the Buttons sheet; as you may have gathered from my earlier post, I prefer tabular formats for this sort of thing.

The problem is that you don't know which device button the upgrade is going to be assigned to.

Good point, I was focussing on External Functions when I said that.

No, this would be the same list as is currently displayed in KM.

Good. I hoped you'd say that. I wasn't clear about your intent because, in your earlier post, you said

Any (non-device) buttons with keymoves

Regarding the "companion" layout, it seems to me the main value of the layout is in providing visual feedback on current button assignments. But, without access to IR.exe, the companion layout on the "exported functions" page couldn't serve that purpose. It could, of course, be used to specify bound device/key, but little else. Presumably, a drop-down menu will be available for specifying those same items in tabular form. So, once again, I question whether a companion layout is worth the effort in this case. But (like I said before) it's your effort.

One of the goals of RM was to be more "user-friendly", by attempting to hide some of the complexity of JP1. One way to do that was to interact with functions in the same way regardless of whether they are assigned to keys in the button map, are for the current device but assigned outside the button map, or are for a different device altogether.

That's why I was suggesting the possible integration of keymoves and external function specification. But, both you and Mark's have expressed concern about the potential confusion for novices. Given their distinctly different end-purposes, keymoves and external functions could quite reasonably "live" independently.

It's not just a matter of entering data, it also a matter of displaying the data.

Once RM decides what type of data has been input, couldn't it record that fact (internally) and display in the same format, without the need for a user to intercede. Unless I've missed something, any data to be displayed on this sheet will have previously been user-entered. Given the nature of the data we're talking about here, there would seem little liklihood that a user would need to see the data in a format other than that in which it was entered. Sorry, I just have a penchant for not having to tell a computer something it should already know or be able to figure out for itself.
Don