RMIR: Prototype IR function in RM

[gfb107]

I am having trouble with jiggling screens, and fields not updating when I make changes. There are a number of things going on, but since this is just a preview I don't know if I should report these as errors, or just be quiet and observe.

Please report any errors you encounter. The more communication the better.

If you don't report issues, they most likely won't be addressed in any way. The response may be "we already know that", or "we found the problem and we have a fix that will be included in the next preview/release", or "we can't duplicate that, how exactly did you get that to happen", or "gee, we never thought someone would try to do that in that way", or "sorry, for now that's just the way it is but we're considering changing it for a future release".

[gfb107]

So I just tried preview3. Considering 27 pages and several years passed, I'm no longer sure what to expect in RMIR.

Sorry, that's my fault. At one point I was keeping the RMIR To-do List and Wish List thread up to date, but I haven't kept up with it.

At the moment the most accurate place to figure out what's been changed and/or added is the ChangeLog, which includes the entire history of changes made to RM and RMIR. That link always gets you the very latest version of the ChangeLog, but the version distributed in the zip matches the moment in time when the distribution was created.

[gfb107]

xnappo, you must be so frustrated by all of us coming out of the woodwork

I think the opposite is true, at least for me. A lot of work has gone into RMIR over the years, and in the last few weeks. It is rewarding to see people trying and providing feedback.

I haven't reprogrammed my remotes in years, so everything that's changed in changed in RM/RMIR had come about because of user feedback or from my desire to get RMIR to the "RDF Feature Complete" state so that we can really start to experiment with taking the UI in different directions that better serve the needs of novice, intermediate, advanced, and expert users.

The RMIR UI as it stands today is incomplete. All core (in the RDF specification) function should be there, even if not easily accessible. But we couldn't really tackle revamping the UI until the core function was coded and mostly bug free. That's what version 2.00 is all about - getting the core function in place, tested and fixed.

Some percentage of users, especially new users that aren't pushing the limits of their remotes will find using RMIR much simpler than using RM/KM and IR.

Some intermediate users (e.g. xnappo, mathdon, and myself, although we are clearly biased in favor of RMIR and some would consider us advanced rather than intermediate) will find that RMIR does everything needed better than RM/KM and IR.

Truly advanced and expert users will find RMIR cumbersome to use for many tasks they perform on a daily basis. Maybe so cumbersome that it is unusable. We acknowledge that. We're going to work on that. But we have to get the core function in place and into the hands of lots of users to make sure it is solid first.

We hope you advanced and expert users will continue to try RMIR, keep up with the changes and enhancements we make, and most importantly give feedback. We won't get there without you.

[gfb107]

There has been a lot of "back and forth" conversation between the RMIR developers and the rest of us about what should be in RMIR, where the developers seem to be in agreement that the "tie all the parts together" approach is the way to move forward, and most of the actual users seem to be saying "stop hiding everything from me".

So here's how I think things need to proceed.

The first official release of RMIR should do, or at least it should try to do, everything that the current IR can do, which means, show all of the protocols in the Protocols tab and show all of the keymoves in the Keymoves tab. In addition to that, RMIR can still do things that IR can't do, such as incorporating protocols and/or keymoves into the upgrade display.

Sure, this means that keymoves may be displayed in two places, likewise for protocols, but that's OK. In fact, I think it's the only way we can move forward with this, because without it, you'll never get IR users to switch over, at least not the experts.

That may well be where we end up. But you all seem to be under the impression that showing all keymoves on the keymoves tab, and all protocols on the protocols tab is something we could do in just a few hours of work. That is not the case. It is a BIG job. That's why it hasn't been done yet. It would take a lot of work to keep those three tabs in sync with each other as changes as made in each of those tabs, and to keep the user informed of things that shouldn't be done or that might have unintended consequences.

[gfb107]

The problem is that there are two protocols, Panasonic Combo and Denon-K, in protocols.ini that have identical codes but different translations between hex and OBC. There is no way any software can distinguish which one is in the upgrade. RMIR identifies the first matching one that it finds in protocols.ini, which is Denon-K.

Can the user simply change the selected protocol to the correct one and have everything display correctly? I ask because it's my experience that RM doesn't change protocols very well as it will often blank out device codes and/or entire columns of data.

You should be able to do this, but it doesn't always work, and that must be fixed. The reason it hasn't been fixed is probably simply that we haven't needed to do while using RM or RMIR.

[gfb107]

Protocols need to be managed to make sure that custom protocols are unique. Sometimes two upgrades use the same custom protocol, sometimes two upgrades use different custom protocols, the user has to keep track of this.

There is definitely work to be done for manual and custom protocols.

This ties back to one of my earlier suggestions that RMIR could help the user manage this. I like to use $01FF for all custom protocols that I write by hand, because if I tried to give each custom protocol a unique id (that hasn't already been used by UEI, and won't ever be used by UEI) it would be impossible). In most cases, the chances of a single user needing to install two of my custom protocols is not great, but obviously it will happen from time to time. When it does, I would like RMIR to look at the two executors and if they're the same, just save one copy. If the new $01FF executor is different to the existing $01FF executor, RMIR should scan all the other executors to see if the code is the same as another executor (as the user could have added it already under a different PID). If no match is found, RMIR could either find the next free PID below $01FF and select it automatically, or it could give the user the opportunity to select a new PID. Maybe this could be configurable via an "expert" option.

Some good ideas here. Would be good to capture these in a formal feature request. Things like this tend to get lost when they are just another post is a really long thread such as this one.

Once a new PID is selected, the user should be asked to save the RMDU file so that the right PID is used next time the upgrade is modified.

Maybe. Or maybe you want to keep the 01FF PID in the master RMDU for installing it into a different remote that has a different (possibly empty) set of custom protocols installed. OF course there also need to be some way to correlate the installed PID when the master rmdu is reloaded later (because it was changed for some reason).

[gfb107]

No more time for this today. Hope my responses have been helpful. I'll be back, I just don't know when.

[Dilligaf]

Tried opening old rmir file and couldn't, so tried downloading from remote and got this error:
http://www.hifi-remote.com/forums/dload ... le_id=8911

The remote works fine, is upgrade overflow supported?

[mathdon]

The remote works fine, is upgrade overflow supported?

The ability to overflow one memory section into another, which can be done in IR.exe, is not yet supported in RMIR.

[mr_d_p_gumby]

]This ties back to one of my earlier suggestions that RMIR could help the user manage this. I like to use $01FF for all custom protocols that I write by hand, because if I tried to give each custom protocol a unique id (that hasn't already been used by UEI, and won't ever be used by UEI) it would be impossible).

At one point I was going to suggest using $FFFF for custom protocols and having IR/RMIR translate this into an unused PID, but then the newer remotes came along and $FFFF would be a legitimate PID for them. The idea might still work if RM/KM used a non-hex character in the PID fields. This at least would take care of installing the upgrade.

OF course there also need to be some way to correlate the installed PID when the master rmdu is reloaded later (because it was changed for some reason).

This is the tricky part. IR has no way to know about this, and even RMIR would need the same logic for the case where the user has lost their file and has only the remote download to work with.

[Capn Trips]

Protocols need to be managed to make sure that custom protocols are unique. Sometimes two upgrades use the same custom protocol, sometimes two upgrades use different custom protocols, the user has to keep track of this.

There is definitely work to be done for manual and custom protocols.

This ties back to one of my earlier suggestions that RMIR could help the user manage this. I like to use $01FF for all custom protocols that I write by hand, because if I tried to give each custom protocol a unique id (that hasn't already been used by UEI, and won't ever be used by UEI) it would be impossible). In most cases, the chances of a single user needing to install two of my custom protocols is not great, but obviously it will happen from time to time. When it does, I would like RMIR to look at the two executors and if they're the same, just save one copy. If the new $01FF executor is different to the existing $01FF executor, RMIR should scan all the other executors to see if the code is the same as another executor (as the user could have added it already under a different PID). If no match is found, RMIR could either find the next free PID below $01FF and select it automatically, or it could give the user the opportunity to select a new PID. Maybe this could be configurable via an "expert" option.

Some good ideas here. Would be good to capture these in a formal feature request. Things like this tend to get lost when they are just another post is a really long thread such as this one.

Greg, even though it's not my idea, I went ahead and added it to the feature request section over at Sourceforge. Hopefully it is locatable and trackable there.

[Dilligaf]

Tried opening old rmir file and couldn't, so tried downloading from remote and got this error
http://www.hifi-remote.com/forums/dload ... le_id=8911
The remote works fine, is upgrade overflow supported?

After thinking about it I think that I programmed my remote before overflow was allowed. I can download my remote in IR using the same rdf and in IR I show 18 free in upgrade memory and no overflow, RMIR shows -4 in upgrade memory. Why the difference?

Mike

[gfb107]

One thing that would make life easier working with upgrades would be to give KM files an extension that we could associate with RM. I'd like for KM to save and open files with an extension other than txt if possible. I realize this is a huge deal, but I think it would be worth the effort in the long run.

This would be helpful.

Back to the main topic, just to throw another huge monkey wrench into the works, I'm thinking of a totally different paradigm. I think when you open RMIR, the first thing you should see is a picture of the remote (the is one of the best things about RM), like the layout tab in RM. Then click a device button (or phantom device button) to assign a setup code or macro. Those details could show on the right like the general tab does today. The other stuff on the general tab (VPT, etc.) could be managed there too. Clicking buttons other than device buttons would let you manage macros, keymoves or learns associated with that button or the whole device upgrade for the active device mode. The other tabs we're used to seeing in IR are great summary views and should be accessible in one form or another, but the bulk of remote management should be accessed from that first graphical page.

A few more specifics on this home/main page I'm talking about. If you click a device button, that sets the active device. If you click any other button, it shows the layout tab in RM for that device upgrade with the button you clicked highlighted. If the button is associated with a device other than the active device, you're given the option to manage keymoves or macros (or learns or special protocols).

Now we're getting to some interesting stuff.
If the main part of the UI is going to be an image of the remote, I think we'll want larger images than we currently have for most remotes.

I'm going to have to think about this one a bit more.

[gfb107]

Tried opening old rmir file and couldn't, so tried downloading from remote and got this error The remote works fine, is upgrade overflow supported?

If you still have your old RMIR file, please upload it to the diagnosis area and provide a link so we can figure out why you couldn't open it.

As already answered, RMIR doesn't support upgrade overflowing.

[Dilligaf]

The problem is that the upgrade doesn't overflow in IR, RMIR is counting the memory differently.

For some reason I can't find the file in the diagnosis area after I download it, I tried twice. I zipped it and still can't find it even though it says upload was successful. I'm on the wifes laptop, I'll try again later on my PC.

Found it here http://www.hifi-remote.com/forums/dload ... le_id=8915

Mike

Edit: When remote is downloaded with IR v1.86 using RDF version 1.28 I show 18 free as in IR with no overflow. Here http://www.hifi-remote.com/forums/dload ... le_id=8916 is a file that overflows in RMIR and not IR