JP1 Remotes

Hi... can someone post a working link to the latest RM? Sourceforce has been down for a couple of days and doesn't look like its coming back too soon.

bbking67 wrote:Hi... can someone post a working link to the latest RM? Sourceforce has been down for a couple of days and doesn't look like its coming back too soon.

Unfortunately the RMIR zip package is too large for the file section of this website, which is why it is only on SourceForge. I understand it is expected to be up again later this week.

I was really thinking of a Mega link or some other free file host.

SF download is working fine for me:

http://sourceforge.net/projects/control ... urce=files

I have now posted build 6 of RMIR v2.03. This new build is available both as a complete installation file and as an upgrade to any of the earlier builds, both from the link just given. Note that build 5 was not publicly released, so this is the first update since build 4.

The main changes from build 4 are:

• Many new protocols for remotes with MAXQ processor added to protocols.ini
• Updates to RDFs for OARI06G and OARUSB04G and to the map for OARUSB04G
• Improvements to certain defaults and error messages
• Addition to the RMIR program of features required to support Extender v1.03 for URC-6440 and OARUSB04G
• Inclusion of RDFs for these two extenders.

There is also a small number of minor bugfixes.

Please note that the forthcoming Extender v1.03 for the URC-6440 and OARUSB04G requires build 6 of RMIR. Certain of its features will not function properly with any earlier build.

In working with these programs heavily the past few days, I've come to encounter some niggles that could be addressed if I'm being overly analytical. None of these are, per se, essential, but you guys have worked so hard on these and made them so polished, I figure you may want to know what I've encountered as a user in the name of continual improvement:

- Multiple monitor focus - when I work on one display, the file OPEN boxes do not stay married to the display you're on. This makes the opening/saving/RM windows tedious to dart all around and find when you're blasting through upgrades
- SAVE AS - on occasion, after you SAVE AS a file with an existing name, I find the current file name doesn't change -- rather it stays as the original causing unwanted overwrites - I can't reproduce this on-demand, but happened more than once, oddly
- ESC key usage - when opening a device, or many other windows, for that matter, and no edits are made, the ESC button does nothing, when it would be great if it could be used to back out, same goes for arrow keys on dialog confirms. It just ends up requiring a lot more keyboard shuffling
-Macro programming mouseovers... this was one that really sapped time - every time I hovered, even for a split second, in the boxes for moving keys in a macro, the help dialog popped up and was in the way -- it wouldn't move until I got the mouse off the box, then I had to dart back in to get the key moved over -- perhaps increasing the time before mouseovers appear would be good?
-Not a bug, but a completely selfish request/idea - has anyone considered an emulator for JP1? Coding and programming time would be cut into a fraction if a program were able to emulate what the RMIR file was going to do based on button presses - macros could be executed, etc. If you take the "plug-in and walk around the house" time out of it, wow...


That said - amazing work, as always, and I'm very grateful for the scores of hours put into these tools which make our ability to harness these remotes beyond that of any remotes costing quadruple. It's this kind of garage-level tinkering and homebrew tech that I love. Now that so much tech has been dumbed down for the masses, JP1 is one of the few areas I have left that are still sufficiently geeky and cool and offer a unique sense of satisfaction to work with.

Thank you.


-N

Just some random comments:

ncoig wrote: - Multiple monitor focus - when I work on one display, the file OPEN boxes do not stay married to the display you're on. This makes the opening/saving/RM windows tedious to dart all around and find when you're blasting through upgrades

As far as I am aware, Java/Swing (and awt) simple does not have a model for multiple monitors, it is just one coordinate system (0,...,x_max, 0,...,y_max).

I think that splash screens exactly in the middle of the "extended" screen, (i.e. with the left half on the left monitor and the right half on the right monitor) is really ugly...

-Not a bug, but a completely selfish request/idea - has anyone considered an emulator for JP1? Coding and programming time would be cut into a fraction if a program were able to emulate what the RMIR file was going to do based on button presses - macros could be executed, etc. If you take the "plug-in and walk around the house" time out of it, wow...

I asked the same question here. But there are also potential legal problems, since a useful emulator has to ether contain UEI rom code, or re-engineer it.

ncoig wrote:If you take the "plug-in and walk around the house" time out of it, wow...

Are you aware of the IR Widget? None of my development testing is done against real devices, it is all done by reading the signals with an IR Widget, which shows you exactly what is being sent by the remote. Despite information in other threads to the contrary, IR Widgets are still available. Google "ir widget (infrared signal recorder/decoder)" exactly like that, including the part in brackets but omitting the quotation marks. The top entry returned tells you how to get one, the second entry gives you a lot more details of what it does.

ncoig wrote:SAVE AS - on occasion, after you SAVE AS a file with an existing name, I find the current file name doesn't change -- rather it stays as the original causing unwanted overwrites - I can't reproduce this on-demand, but happened more than once, oddly

The known, and deliberate, situations where this occurs is when you use Save As to save a file of one type as a file of a lesser type, i.e. one that stores less information. So if you save a SimpleSet .bin file as a .rmir file, or either a .bin or .rmir file as a .ir file, the current file does not change. If it happens in other situations, it is a bug but I need a reproducible instance to find and fix it.

-Macro programming mouseovers... this was one that really sapped time - every time I hovered, even for a split second, in the boxes for moving keys in a macro, the help dialog popped up and was in the way -- it wouldn't move until I got the mouse off the box, then I had to dart back in to get the key moved over -- perhaps increasing the time before mouseovers appear would be good?

I have to agree with this one. I think it is extremely irritating because of the time I waste getting rid of the pop up that is always obscuring the very thing I need to click. OK, not always, but Murphy's Law applies the majority of the time.

In RMIR there are two styles of tooltip behaviour. In tables tooltips are used, amongst other things, to display the entire content of a cell when it does not fit into a single line. For this reason they display immediately and remain showing, but can be dismissed by clicking the cell. It doesn't matter if you click the wrong cell, as a single click does nothing, it takes a double click to edit a cell.

Elsewhere than in tables, tooltips have the default Java behaviour of appearing after 750ms. I take it this is the behaviour in question, as the macro editing dialog has this behaviour. I can change this initial delay if desired, but it will change everywhere (except in tables). I don't myself see it as much of an issue, as it is still true that you can just click the mouse (once) to get rid of the tooltip without it performing any action other than selecting a value.

mathdon wrote:In RMIR there are two styles of tooltip behaviour. In tables tooltips are used, amongst other things, to display the entire content of a cell when it does not fit into a single line.

And this behavior makes sense and works well, AFAIK.

mathdon wrote:Elsewhere than in tables, tooltips have the default Java behaviour of appearing after 750ms. I take it this is the behaviour in question, as the macro editing dialog has this behaviour. I can change this initial delay if desired, but it will change everywhere (except in tables). I don't myself see it as much of an issue, as it is still true that you can just click the mouse (once) to get rid of the tooltip without it performing any action other than selecting a value.

Well, yes and no. I just double-checked and here's the precise scenario that is most disconcerting: Let's say you open that macro editing box and in the "available" keys section you have a list 8 lines long. So you stick your cursor in that box and begin scroll-wheeling it down. if I come in from the top of the box (or anywhere near that), the 4-line long and wider-than-the-available-keys-box pops in immediately (my i7 may be quicker on the draw, but it sure seems like less than 750ms) and now obscures the majority of the box. If I click once in there, the popup just moves down to where I clicked, but is still in the way. I now have to click a second time to eliminate the box. I can select my command on my now-third click, rather than one. I move the mouse down, and in the process, the tooltip reappears as I'm on line 7 or 8, now obscuring all the add/insert/etc buttons. Fully half the time, the "click to remove" you mention results (perhaps because I'm close to the edge) in the action underlying the obscured button to be executed, and half the time it doesn't. So, my 15-line macro may or may not have now been ADDed an unwanted command to the end, when I'm trying to INSERT a command instead.

It's really very cumbersome. I'd be happy to screencap what I mean. If I were setup to do a video capture of what I mean, I'd happily do it, but I think you get the picture.

Again, I have made do and mean nothing negative by it -- I'm so happy to have active development, I'd put up with far more!! -- but again, when you're in there fiddling, perhaps an option to turn off help tips or at least adjust that time to like 2 seconds, or make it variable in a setting?

-N

mathdon wrote:

ncoig wrote:SAVE AS - on occasion, after you SAVE AS a file with an existing name, I find the current file name doesn't change -- rather it stays as the original causing unwanted overwrites - I can't reproduce this on-demand, but happened more than once, oddly

The known, and deliberate, situations where this occurs is when you use Save As to save a file of one type as a file of a lesser type, i.e. one that stores less information. So if you save a SimpleSet .bin file as a .rmir file, or either a .bin or .rmir file as a .ir file, the current file does not change. If it happens in other situations, it is a bug but I need a reproducible instance to find and fix it.

That may be the case, but it results in an overwrite of a file that I may not have wanted to do with no indication all the same. (yes, other than the title bar, but who looks at that?? )

Now that I know that, I can keep a closer eye, since that is probably what happened since I work with a lot of .IR .TXT files from a dog's age ago.

Thank you for the explanation.

-N

Barf wrote: I asked the same question here. But there are also potential legal problems, since a useful emulator has to ether contain UEI rom code, or re-engineer it.

Fiddlesticks. Console video games have long been emulated, and the emulators never contain the ROMs. Those have to be, ahem, self-procured. Legal quandary solved. Sure, sure, one could make the argument for contributory infringement, but I have never once heard of Nintendo, TI, or any other company blazing a path to some open source programmer's house over an emulator...

-N

[and here comes the news links, I'm sure ]

Barf wrote:Just some random comments:

ncoig wrote: - Multiple monitor focus - when I work on one display, the file OPEN boxes do not stay married to the display you're on. This makes the opening/saving/RM windows tedious to dart all around and find when you're blasting through upgrades

As far as I am aware, Java/Swing (and awt) simple does not have a model for multiple monitors, it is just one coordinate system (0,...,x_max, 0,...,y_max).

I think that splash screens exactly in the middle of the "extended" screen, (i.e. with the left half on the left monitor and the right half on the right monitor) is really ugly...

Agreed, however, when I open the macro edit, it stays in the same display. When I open the device, it stays with the display. When I "Open" within that device, off we go to display 1 instead of the current display. Surely there's a different call for those items, but couldn't they all be called the same way?

-N