JP1 Remotes

I have several remotes and sometimes I see a jungle of inconsistencies in my designs. It's not that simple to keep things simple over time.

One of the IR annoyances for me is the separation of the special protocol keymoves, much as I love it an use it. Because between the two keymove places, plus the macros, plus the upgrades without the notes, it's rough to find things. Another is the macros vs DSMs.

Often IR says you already have a keymove or something on that button. Great. Where is it? So ... nothing 'hidden' please.

In addition to things recently discussed here, what I'd love to see in RMIR is ONE LONG LIST of ALL the buttons regardless how they got into the remote. A system state of sorts.

There could be columns as we now know them in upgrades, and other sheets/tabs with additional columns for the orgin (upgrade or some other source).

It would need columns for 'disjointed' things - like macros and keymoves on one sheet could get nasty. But I've seen some discussion of XML use here, so perhaps one list thrown into an XML file, and displayed from a up-to-the-second XML scheme, would do the job.

I'd like to be able to sort by every column possible: device, setup code, type of keymove, macro including DSM, Fav, upgrade or not, etc.
Finding, editing, deleting, making a cleaner system would be simpler then.

I'll try to fire up the newest RMIR in the next few days to see the recent improvements 'cause it's been a while since I used it (v1.96 I think). I had some download from remote issues then I think.

xnappo wrote:That is what I was getting at - the whole tab is not very useful in the RM-IR paradigm.

Therefore, if you regard the whole tab as not being very useful, you're not the best person to ask what should and shouldn't be in it. Personally, I find it very useful and I'd like it to continue to exist and for it to show all of the keymoves that are in the remote (including the special protocols, which I don't think should have been separated from the keymoves and macros tabs in the first place.

That being said, I do like the fact that RMIR recognizes that a keymove "belongs" to an upgrade and I like the fact that RMIR has the ability to delete them in the event that I delete the upgrade, I just don't like the way that it decides to hide some keymoves and not others. (Hint: there's nothing wrong with a keymove being displayed in multiple places).

There's obviously a school of thought here that says it's a good idea to dumb things down a bit for the common user, and I'm not opposed to that, after all, many people are scared away by all of the hex code that is still visible all over the JP1 tools, but there has to be a way for us to see the whole picture without having to compile bits of info from multiple places.

I find myself in agreement with what Rob is saying. I see nothing wrong with what Greg is trying to accomplish with RMIR, but I don't see a need to throw the baby out with the bath water either. IR, despite its flaws, has developed over time into a very sophisticated and useful tool, and I would see it as a step backwards to remove functionality that is found useful to many users. I also see the benefit of the RMIR approach for novice users. IR has many options for advanced users, and I would think it appropriate for RMIR to do the same.

While we are all concentrating on keymoves here, let me throw another aspect into the mix:

"When I am in the main part of the application, there is a tab called 'learned signals'. This appears to be some sort of centralized place to edit the buttons without going into the device key assignment one at a time, however only some of my key assignments are showing up there. Why???"

We have had some recent users treat learned signals as part of their upgrade, so will they also expect them to be treated the same way as keymoves?

Thanks Mike, and I think having the ability to make learned signals be treated as part of an upgrade is a good idea, so that when the user gets rid of that piece of equipment, deleting the upgrade could delete the learned signals too.

Also, if RMIR is going to delete keymoves and/or learned signals when an upgrade is deleted, I would like the user to get a pop-up message asking them first, I wouldn't want it to just delete them without user confirmation.

Most people would not have many keymoves if they used RM-IR. I have over 40 in my IR setup. Rob IF you switched the the RM-iR paradigm, what would you use the keymoves tab for(I mean what would not be in an upgrade)?

I really don't understand why my posts are being taken as 'we should not have an option to show all the keymoves on the keymoves tab'.

That is not what I am saying!

What I AM saying is is there another, even more useful feature that we could add even on top of that that would be MORE useful.

1. I think Elizabeth's suggestion is along those lines. That would be VERY useful - especially when people don't know the priority of macros/keymoves/upgrades.

2. I think it may also be useful on the 'General' or maybe 'Devices' tab to have columns for 'upgrade', 'keymove' and 'learning' memory.

3. I think showing the 'Output' tab information in a more human readable form would be useful.

4. The comment about learned signals is spot on. Is there anything from an upgrade sharing point of view we would need to be concerned with if we stored learned signals in a .rmdu file? I guess the most obvious is that most people don't have learning remotes... Definitely something to think about.

xnappo

I'm not suggesting that learned signals be included in the RMDU file, but I think they could be linked in the RMIR file.

What would I use the keymove tab for? To see what keymoves are in the remote. Keep in mind that the first time someone downloads their remote's memory, anything in there was programmed WITHOUT using JP1 tools, so who knows what's there.

If all the details are hidden, people will create upgrades treating all the buttons as equal, where they're not equal. Assigning a function to a button that's part of the keymap doesn't use up any macro memory, whereas programming another button does use up macro memory. Maybe I created some of my upgrades ages ago when I had plenty of memory to spare and now I need to trim some of the fat in order to add some steps to a macro, so I'm going to go looking to see what functions ended up as keymoves. I surely don't want to have to step through my 20 upgrades, what I want to do is see all my keymoves at once so I can decide if there are any that are not really needed.

I'm willing to keep this discussion going if needed, but I don't think there's much point to it. I think it's pretty obvious that there's a bunch of us that want to be able to see all of our keymoves. Can we just accept that and move on? Likewise for protocol upgrades.

When RMIR is ready to meet our needs, I'm sure we'll all switch over, but in the meantime, we'll continue using IR.

I appear no to be communicating efficiently, so I am going to let it drop.

Rob - you are misunderstanding me, but I am tired of trying to explain.

xnappo

One other useful distinction as to the source of things are external functions - those coded in KM or RM and go with an upgrade. It's good to know where they came from.

Incidentally, I mentioned XML file as a possible temporary vehicle. I hate XML files so I'm not pushing it. I'd rather just see a wide spreadsheet and columns that can be filled, and are relevant, would be, the rest would be blank.

Hi everyone sorry to have created such a storm here of the hidden Key Moves and Devices but I for one want to see them.

Xnappo one example I will use is I like the fact I can just click on the Key Moves Tab or the Devices tab and see all the key Moves so when I am testing or rebuilding a remote and need to check a button I assigned a key move to I can see all the information like the EFC now you will say why do you need to see the EFC well when doing testing with the IR WIDGET it sure make it nice to know the EFC. When I am testing a Macro and I am not getting the response I was looking for it’s nice to know what EFC the macro sound be sending and it is quick to click on the tab and check the key to see if the correct EFC is in fact associated with the key. The same goes for the Devices now I have been playing with RM IR more and more and I realize I can get the same information by double clicking on the device and then selecting the functions tab in Device Upgrade Editor two extra clicks and another popup window to get the information I NEED now I do not want to edit anything I ONLY want to see the information.

Hope these examples help I really appreciate all the work everyone is doing and not trying to be a jerk but I want to see the information or at least an option to show it. I will have to agree with The Robman if you want us to change over to the new program we need some of the same functionality that is in the current IR. Building a new program does not mean forget about everything you used to do because we have a better idea we have been using IR for a long time now think of it a backwards compatibility (User Stile)

Thanks,
Dolivas

The Robman wrote: Also, if RMIR is going to delete keymoves and/or learned signals when an upgrade is deleted, I would like the user to get a pop-up message asking them first, I wouldn't want it to just delete them without user confirmation.

I haven't read back to the point where this was introduced, and I haven't used RMIR yet, but I would really hate my keymoves to be deleted when I delete my upgrades, because I nearly always delete my upgrade after I paste it in, because my upgrades are really the built-in setupcodes with all the extra advanced codes that I want on the shifted keys.

I ditto what Vicky just wrote. Need an option to "also zap keymoves", which in some circumstances is needed.

ElizabethD wrote:I ditto what Vicky just wrote. Need an option to "also zap keymoves", which in some circumstances is needed.

That is already covered by Capn's request which Greg has accepted:
https://sourceforge.net/tracker/?func=d ... tid=399669

KM Device upgrades frequently include embedded KeyMoves and Protocol Upgrades, RMIR makes these transparent to the user and does not display them in the KeyMove and Protocol Upgrade Tabs, respectively. There are occasions when the user needs to be able to more readily access these elements directly from RMIR rather than having to open up the associated Device Upgrade. A user-selectable option to DIS-associate Keymoves and/or Protocol Upgrades from an associated Device Upgrade is required to make this possible.

xnappo

Okay, I give up, WHERE IS IT? I can find remotemaster, but can't seem to find RMIR. Its not in the tool section here, so I went to Source forge, but RMIR is talking about gene RNA so I don't think that's the software.

Vicky, on that RM page, hit TRACKER and select FEATURE REQUESTS. There are some lines about RMIR there.

Just for clarification RM and RMIR is a single java package handled under the Remote Master project on SourceForge