JP1 Remotes

The information about keysets isn't currently available in the RDF. I tried using the groupings in the ButtonMaps, but that didn't work, here's what I ended up with:


If this is something we want RM to be able to do automatically (in which case RM would just use different outline colors for each keyset, leaving yellow as the default for either

1. keys that aren't in a keyset, or
2. RDFs that don't specify keysets

), we'll have to come to an agreement about the RDF syntax for it. Note that I think keysets are really an extender concept, and don't apply to unextended temotes.

I kind of figured the ButtonMaps would not get it completely since they are not defined for the purposes we would think they are for.

If we are just talking about base buttons that are visible on the remote then I agree, if we come up with a syntax for the RDF that RM could use we would be good to go. I also think it is something for both extended and unextended remotes but ironically they could be different since we tend to add groupings (like other) in the extenders that are not in the base.

It will be a lot of work in RM and a lot in the RDF's so I would be interested in how many people really want it before we dig into it.

Nils_Ekberg wrote:I kind of figured the ButtonMaps would not get it completely since they are not defined for the purposes we would think they are for.

We're talking about "Home Theater" key sets right? (I couldn't tell for sure from that other thread). ButtonMaps doesn't even give you a clue about those (other than the trivial special case of vol keys).

Nils_Ekberg wrote: If we are just talking about base buttons that are visible on the remote

That's something entirely different from HT key sets.

Nils_Ekberg wrote: I also think it is something for both extended and unextended remotes but ironically they could be different since we tend to add groupings (like other) in the extenders that are not in the base.

HT key sets do apply to unextended remotes as well as extended. They are different. Some remotes have key sets extended but not unextended. Some extenders have different key sets than the same remote unextended even though the unextended remote has key sets. Even the "other" key set exists and has significant diferential behavior non extended (it just isn't well documented or convenient behavior).

Nils_Ekberg wrote: It will be a lot of work in RM and a lot in the RDF's so I would be interested in how many people really want it before we dig into it.

Helpful feature, but I worry the screen would get too busy and anyway I don't think it's worth the work.

johnsfine wrote:We're talking about "Home Theater" key sets right? (I couldn't tell for sure from that other thread). ButtonMaps doesn't even give you a clue about those (other than the trivial special case of vol keys).

Yes

johnsfine wrote:

Nils_Ekberg wrote: If we are just talking about base buttons that are visible on the remote

That's something entirely different from HT key sets.

I was just thinking a long the line that every physical button on the remote is in one HT group or another. For all intents and purposes even buttons not in HT groups would fall into the "other" category.

johnsfine wrote:

Nils_Ekberg wrote: It will be a lot of work in RM and a lot in the RDF's so I would be interested in how many people really want it before we dig into it.

Helpful feature, but I worry the screen would get too busy and anyway I don't think it's worth the work.

I have no doubt that the screen would be too busy. An alternative might be to regroup the buttons in the Buttons panel to the logical grouping or something like that but I am not sure if that is what is being asked for or worthwhile.

This discussion of KeySets is fascinating, and sure, I would like them highlighted or identified somehow in BOTH RM and IR, but it appears to me (granted from the outside, as I am NOT the one doing the programming ) that color-coding the KeySets - although a noble endeavour, is apparently really too much effort, as each RDF, image and MAP file would have to be specifically tailored (I realize they will all have to be tailored for the initial project anyways, but this is another level, apparently) and the display would really get too busy to be practical, not to mention the RM program changes. I see no great outcry for this additional functionality, but there did appear to be some interest in the original two feature requests:

Capn Trips wrote:(1) to display the various "phantom" buttons on the "Layout" tab alongside or below the picture of the remote?

and

(2) position the cursor over a function (or click on it), for it to display what button(s) has(have) that function assigned?

There seemed to be general agreement on a way ahead with this before the discussion got sidetracked. Might I respectfully suggest we (by that, of course, I mean "YOU" ) table the expanded KeySet brainstorming, and see if the initial features requested can be implemented ?

I'm almost ready with the changes for this. I ended up going a different way than I originally thougt. Tell me what you think.



As you can see, the phantom buttons are little circles below the image of the remote. In that image, the selected button is Shift-Phantom1, which has been assigned the function Discrete On.

You can't see that the mouse pointer is hovering over the tuner function, put you can see the hover help text, which clearly indicates that tuner has been assigned to the Com/skip button.

Note that the same hover help is displayed on the Buttons panel too.

gfb107 wrote:Tell me what you think.

COOL!!!!!

I'm honored that you are using my upgrade as your "test" upgrade. 8)
Of course, there are a lot of image and keymaps files that need to be updated, right?

Now could you have it display when my coffee will be ready?

Capn Trips wrote:Of course, there are a lot of image and keymaps files that need to be updated, right?

Actually, no. I was able to find the phantom buttons in code, and generate the shapes for them in code.

Some RDFs will have to be updated, because there are a number that have buttons that can't be assigned functions but aren't flagged as such.

Here's an example of that:

The RDF's are ready and I just want to make one more quick test to make sure I didn't miss any.

I will try to post them later today.

I've just released the new version that has these changes implemented

It's possible I may have a video problem but with this version when I select a different remote it only replaces the top half of the image for the prior remote. If I refresh the window it then paints the whole remote.

I've got a fix for that, although I'm not sure just that minor change is enough for a full release. I can send you a new .jar file if it would make your life easier.

Thanks Greg. It did since now I don't have to refresh the window everytime I change remotes for testing

gfb107 wrote:You can't see that the mouse pointer is hovering over the tuner function, put you can see the hover help text, which clearly indicates that tuner has been assigned to the Com/skip button.

Note that the same hover help is displayed on the Buttons panel too.

This is definitely an improvement, but I was hoping for something more visual than hover text. I'd like to be able to see which button the function is assigned to, e.g. was it the third or fourth button on the last row? This way you won't have to look at the actual remote to find the button.