RMIR: Prototype IR function in RM

[Capn Trips]

Well yes, both IR and RMIR now know what devices are in the remote, perhaps when a user goes to load a device, if the device is has the same id as one of the built-in devices, a question could be asked, is this a keymove-only load?

I like that idea - makes a lot of sense.

xnappo

Deleting a device could automatically delete the keymoves if there was no built in device of the same device id, and could ask if there was also a built in device with the same device id. Left over keymoves can cause problems for occasional users who are changing out their equipment . Although I really hate it when IR makes any changes without my permission.

I like all of these implementation proposals and have added them to the SourceForge Feature Request comment section.

[vickyg2003]

Personally, I don't want any program deleting anything without asking first.

I agree with that. I have a been a little bit frustrated by all the enforcing that IR does on my behalf.

[mathdon]

Personally, I don't want any program deleting anything without asking first.

Sorry if I sound like Bill Clinton, but it depends what you mean by "anything" . To RMIR a device upgrade is the thing that RM generates, the whole thing that gets imported into IR.exe when you use RM to add a new device upgrade. IR.exe then splits it into the separate bits (raw device upgrade, protocol if needed, and key moves) needed to implement this in the remote. IR.exe then allows you to delete the bits separately. RMIR treats the upgrade as a whole and when you delete the upgrade, it does exactly that, not leaving any extraneous bits (unless any of those bits, such as the protocol, are used by another upgrade). So neither IR.exe nor RMIR deletes anything without you asking for it to be deleted, they just interpret differently the thing you have asked to be deleted.

Suppose I have an old lawnmower to dispose of, and I ask a refuse collector to take it away. He takes the lawnmower but leaves the grassbox. I contact him and say why didn't you take the grassbox. He says you didn't ask me to, you only asked me to take the lawnmower. To me, the grassbox is an integral part of the lawnmower. To him, because it is removable, I should have specified separately that I wanted him to take it. Both are valid points of view.

To return to remotes, suppose a user has had a phone upgrade from UEI that includes a protocol upgrade. To the user, he/she has asked for an upgrade for his DVD player, say, and has received it. That user has probably never heard of a "protocol", but uses IR.exe to delete the upgrade as the DVD player has been replaced with a new one. Junk (the protocol, or grassbox) is left behind, unknowingly taking up upgrade space. Do it in RMIR and he gets what he expected, the junk to be taken away as well.

Perhaps the way forward is to have an Advanced menu with an "Expert" option. When unchecked, the default, RMIR behaves as at present and takes the whole lawnmower, grassbox and all. When checked, it asks whether you want the grassbox left behind.

[The Robman]

I understand what you're saying, and I think for the casual user it will work just fine, but I can see most experts getting completely pissed off with this program continuously deleting things that they didn't want deleted.

How would you like it if the refuse collector not only took away your lawn mover, but also the Rubbermaid shed that it was in? His logic being that if you no longer have a lawn mover, you have no need for the shed?

On the other hand, if the refuse collector were to ask you if you also want him to take away the grass collector and the Rubbermaid shed, that would be OK because you could then tell him what you want him to do. That's all I'm asking, hence the "without asking first" part of my statement.

And back to Greg's earlier point about nobody making a feature request for RMIR to be able to save IR files, can we just assume going forward that there is a feature request that RMIR be able to do everything that IR can do? There isn't a single feature in IR that wasn't specifically asked for by somebody, and that somebody was quite often me, so if ANY of those features are missing from RMIR, it would be a step backwards in my view.

[gfb107]

I think RMIR saving as an IR file doesn't fall into the category of "IR has a way to do this, so should RMIR". After all, RM can't save to a KM file and KM can't save to an RMDU file.

[The Robman]

I think RMIR saving as an IR file doesn't fall into the category of "IR has a way to do this, so should RMIR". After all, RM can't save to a KM file and KM can't save to an RMDU file.

We'll have to agree to disagree on this one then. If RMIR doesn't have the ability to save IR files, how are the experts going to be able to help newbies when they have issues (as we'll need to use IR to see what's really going on).

It would be really messy for us to keep telling these users to load the data into their remotes, then use IR to download the true E2 image.

As RMIR has the ability to load data back into the remote, and I assume at that point it will have to forgo the whole "keeping things as objects" approach and format the EEPROM data, unless I'm missing something, I can't imagine that it's that big of a step to make it also save that same output to a text file.

[gfb107]

It's not a big deal (but it's not trivial either, because Notes are handled completely differently), and I do plan to implement it.

My point was just that this feature isn't in the category of functional parity between RMIR and IR - it is additional function.

RMIR already has a way to save your remote configuration to a file and load it from that file. That is equivalent function to IR saving/loading IR files.

Another point (that was below the surface of my post) is that I need help managing the RM/RMIR todo list. At this point I think the best way to do that is a bug/feature tracking system such as what is available at Sourceforge.

The point is to document everything we know is broken and/or missing, so that we can all see what is on that list and how it changes over time.

I tried using a sticky forum thread for that, and it worked quite well for a short while. But it requires a lot of discipline to maintain and quite a bit of time, and I don't have enough of either any more.

[mathdon]

I have changed the Key Moves display in RMIR so that it shows key moves from device upgrades. These are appended to the display of other key moves (those that show on this tab at present) and are grayed out and not editable. I'm sure someone suggested doing it this way some days ago, but I can't find it so can't attribute the suggestion to anyone. If we finish up with a selectable "Expert" mode then I think this should be an Expert-only feature, but at present it is a permanent feature.

Also, after discussion with Greg, I have removed the prompt about assigning the upgrade to a device button that appears when an upgrade has key moves. It is necessary in IR.exe since otherwise the key moves will be lost. In RMIR they are not lost if the device upgrade remains unassigned. They don't get uploaded to the remote, but they are saved in a .rmir file. Any subsequent time that the upgrade is assigned, the key moves will be created. This is part of what it means to say that the key moves are treated as belonging to the upgrade, and to my mind at any rate it is a positive advantage of RMIR.

I've just committed these changes to SourceForge, so they will be in the next release - unless there is one in the pipeline that they have missed.

[vickyg2003]

Okay, I said I’d TRY to keep my mouth shut. Then I read the lawnmower post and actually SCREAMED!

This is so hard to even post about. I know that my point of view seems to indicate that I like the status quo and want to keep it that way. I know I showed a bit of that when the RDF’s were moved to SourceForge, (sorry xnappo) but that was a resistance to change, but my feelings abut RMIR are not driven by resistance to change..

This is a fundamental difference of opinion. Its such a fine line of disagreeing with another persons opinions, and actually attacking the person. This is especially true when the people that you are disagreeing with are so strongly committed to the opposite opinion and working so hard to see their dreams become reality. So please do not take this attack.

Let me start by disagreeing with Rob.

I think for the casual user it will work just fine, but I can see most experts getting completely pissed off.

I must say I totally disagree about the casual user comment! This new design would have stifled me as a newbie user. You may have noticed I’m not the sharpest knife in the drawer when it comes to understanding the unseen, (If you only knew how I was interpreting what you were saying about infrared signals, you’d have thrown up your hands long ago! )

One of the coolest things for me as a new user was being able to SEE what was going on. I’m a big, look and see person. All of the tools, IR, KM and RM let me easily explore what was going on visually.

I did all sorts of experiments with IR to understand what was going on with the remote memory. This helped me learn how to properly manage memory in my older JP1 remotes with the itty bitty Eeprom. The same thing with KM and RM, I was able to assign functions to buttons and see how they affected the upgrade. For example: I must have read more than 20 posts about how using one number for an upgrade was going to add 10 bytes to an upgrade, but when I used KM and assigned one number I could actually SEE what was meant.

So my comments about what it can’t do, are mearly logical arguments. I’ve been trying hard not to not hurt anybody’s feelings with my passion. But I passionate dislike hiding things from new users. The passion is what is hard to get away from. I am fighting for the dimwits like me who wouldn’t be able to overcome the hidden aspects of this design, to become accomplished users.

Now on to Graham.

To return to remotes, suppose a user has had a phone upgrade from UEI that includes a protocol upgrade. To the user, he/she has asked for an upgrade for his DVD player, say, and has received it. That user has probably never heard of a "protocol", but uses IR.exe to delete the upgrade as the DVD player has been replaced with a new one.

It was when I got to that sentence that I actually screamed. That is my whole point, the user NEEDS to know what a protocol is. This is one of the most basic concepts that a user should know. Understanding what a protocol is, and how it interacts with a setup code is a key concept for the JP1 user. Hiding that, just limits the user’s vision!!!!!!!!

But I’d like to thank you for firing up my passion, as I was so fired up I was able to take an ax out to the back yard and single handedly remove a giant stump!

As for removing a protocol if the device is no longer in use. Again this can be a real problem. Suppose I write a version of a protocol NEC1 for a person with disabilities, that changes the way repeating is done, so that the protocol delays a whole second before sending another first frame followed by repeats. You now delete the device that initially prompted me to write the protocol, and now all there built in devices have the undesired fast repeats?

Having the software think it knows what's best for me, really bothers me.

[The Robman]

I think there are many people who use JP1 because they have to, as it's the only way to get their remotes working, but have very little interest in how it works or why it works, so for casual users like this, it's not in appropriate for the software to make some decisions for them. It's kind of like when you install new software and it gives you two choices, "Standard (recommend)" and "Custom". There are a lot of people who get scared the minute they see hex codes.

As for the rest of your points, I think it's pretty much been accepted now that RMIR is going to be a tool for the casual JP1 user, with the experts continuing to use IR.exe, at least until such time that RMIR can do everything that IR can do, and it can be made to not do things we don't want it to do, like deleting stuff, etc.

And just FYI, built in setup codes always use built in protocols, they can't see protocol upgrades.

[vickyg2003]

And just FYI, built in setup codes always use built in protocols, they can't see protocol upgrades.

I'm pretty sure that I tried on a JP1.2 remotes, and found that it would see the protocol, but ONLY if there was at least one device in the upgrade area.

I'd like to take a look to confirm, but my cable/remote connection is really having troubles today.

[The Robman]

I suppose it's possible that the rules changed with the flash remotes, but that's certainly how it was with the EEPROM remotes.

[ElizabethD]

Still on Preview3.
I'm doing my best to use RM and RMIR.
I just saw posts about wonderful changes, but haven't absorbed it.
However, I want to first edit, in any RM version there is, something simple in KM and here I can't seem to figure out how:
Device upgrade is a bundle of 3 devices, 2 as external functions. I want to get rid of a bunch of those external functions. I selected all the relevant rows but can't delete.

Of course I can go to KM and do it, but is there a way here?

[gfb107]

2 things:

1. You can only delete functions that are not assigned to buttons.
So first you must unassign the functions, then you can delete them

2. At this time you can only delete one row at a time. You may select multiple rows, but only the top deleted row will be deleted.

[ElizabethD]

Thanks, Greg. Yes, I found both points to be like you said.
I'm actually doing major changes here, including some new gear, and found a file without those external functions.

So a request - multiple rows deletes, please.

In any case I will try the latest preview as time permits 'cause it sounds pretty nice.