RMIR v3.0 Major new release!

[mathdon]

Edit: The latest version is now RMIR v3.0.15.

RMIR v3.0.0 is now available.. It is a major new release that involves restructuring, updates and additions. All users are encouraged to update to this version. All remotes benefit to some extent, with more advanced ones gaining the most. The most visible change affecting all remotes is the identification of clashes between key moves, macros, special functions and learned signals by means of "traffic light" highlighting. This would not have been possible without the restructuring. Details of this and other changes are given separately in the post that follows this one.

The supported platforms continue to be 32-bit and 64-bit Windows, Linux and Mac OS X, together with experimental support for Raspberry Pi. This version, like the others since 2.09, requires Java 8 or later. All later Java versions are supported, the current long-term support version (LTS) being Java 17, released in September 2021. Oracle has recently changed the way Java is licenced and distributed, as described in this informative article.

RMIR supports all currently known types of UEI remotes, including XSight and Simpleset remotes. UEI has closed down the EZ-RC.com website that provided support for XSight and similar remotes. RMIR provides complete replacement support for these remotes, including the ability to upgrade the firmware to the last version that UEI issued. XSight users new to RMIR, especially ones who have been directed here from the legacy page at EZ-RC.com, should read the Wiki article Getting started with XSight and Nevo for further information. No special action is needed to perform a firmware upgrade on an XSight remote. Just do a download in the usual way. If a firmware upgrade is available it will be offered. You may install it or not, at your choice, and if you choose not to install it, you are given the opportunity not to be offered the upgrade again in future.

RMIR incorporates version 1.2.12 of IrpTransmogrifier by Bengt Martensson (Barf). This is a program for decoding, analyzing and rendering IR signals that is used by RMIR but is entirely separate from it. Command-line access to IrpTransmogrifier itself is available if required through the command files irptransmogrifier.bat (for Windows) and irptransmogrifier.sh (for Linux and Mac OS X) in the RMIR installation folder.

The XSight and Simpleset remotes are supported by RMIR directly via their USB interface, without the need for any cable other than the USB lead supplied with the remotes. Other remotes are supported through their JP1 6-pin connector with JP1.x interface cables. A few remotes, however, have an external 5-hole connector rather than the 6-pin connector in the battery compartment that is common in UEI remotes. These need an adapter to convert the 5-hole connector to the standard 6-pin one. Detailed instructions for making such an adapter are given here. Previously, strong advice has been given to use only interfaces with a genuine FTDI chip. The current jp12serial library is believed to work, for all remotes, with all available USB-to-Serial converters that have TTL-level voltage outputs and in particular with those with a Prolific chip whose use was previously discouraged, though some cables have counterfeit FTDI chips and these should be avoided.

Remotes that support the Bluetooth UEI phone app can access RMIR through their Bluetooth interface, in several ways. All supported OS platforms can do so with a BLED112 Bluetooth dongle. Windows users have two additional access methods. One uses the Bluetooth stack that is built in to Windows 10, but the remote needs v2.00 of the Bluetooth extender installed and this installation requires a one-off use of a JP1.x cable. The other is available both for Windows 10 and some earlier Windows versions (but so far only tested on Windows 8.1) and does not require this use of a JP1.x cable, but needs the installation of the BlueSoleil Bluetooth stack. See the Bluetooth thread Bluetooth is coming to RMIR for more details.

To upgrade from v2.12 or later without losing your settings, delete everything in your installation folder other than the RemoteMaster.properties file that contains your settings. Then unzip the new installation package into that folder and you are done. Alternatively, if you wish to keep your earlier installation and port your settings to v3.0, follow the installation instructions below and then copy the RemoteMaster.properties file from your earlier installation to this new one. In this case, however, you will need to use the menu item File > Set Directory to change the locations of the RDF, Images and AddOns folders from being in the old installation folder to the new one.

The RMIR menu item Help > Check for updates checks for new builds as well as new versions. If a new build or version is available then this menu item displays a message containing a hyperlink that will take you straight to the download for the update. This works in any build from v2.11 on, but not with versions earlier than v2.11 due to a change in the SourceForge website that maintains the distributions.

To install RMIR for any OS, first unzip the installation package to a new folder that is not read-only. For a Windows OS this means, in particular, that it should not be unzipped into a subfolder of the Program Files folder. After unzipping it, do the appropriate one of the following:

• If your OS is Windows then run Setup.vbs by double-clicking or otherwise. This will create three shortcuts, one each for RMIR, RMDU and RMPB. They will be created in your installation folder, but they are also copied to Start > All Programs > Remote Master if you are running a Windows version that has a Start menu. You may copy them to your desktop, or any other location, as you wish. Setup.vbs also creates file associations to open .rmir files in RMIR, .rmdu files in RMDU and .rmpb files in RMPB.
• If your OS is Linux then run setup.sh from Terminal as a shell script. If the current directory in Terminal is the RemoteMaster installation directory then the command "sh setup.sh" will run the script. It creates three .desktop shortcuts, one each for RMIR, RMDU and RMPB. They will be created in your installation folder, but they are also copied to your $HOME/.local/share/applications folder to ensure that they appear on your Dash. setup.sh will also add you to the dialout group of users, if you are not already in it. If you need to be added, then it will ask you for your sudo password as this step needs to be run with root privileges. This step is needed to enable RMIR to access USB serial ports without RMIR itself being run as root.
  
  The distribution also contains a text file linux_xsight.rules. If you have an XSight or Nevo remote, you may need to copy this to the directory "/etc/udev/rules.d/". It may be re-named if desired, provided the extension .rules is kept. This file provides a user-friendly name for the XSight as a USB device. Some users have found that Linux systems cannot find the XSight/Nevo remote unless RM/RMIR is run as root, even after running setup.sh, unless this file is present.
• If your OS is Mac OS X then there is as yet no special installation procedure.

With all three OS's, RMIR can be opened without using a shortcut by double-clicking or otherwise running the Java file RemoteMaster.jar. RMDU can be opened from RMIR with the menu item File > New > Device Upgrade and RMPB with the menu item File > New > Protocol. The instances of RMDU or RMPB so opened are independent of the RMIR instance from which they are opened, so you can then close RMIR and leave RMDU or RMPB open if you wish. RMDU can also be opened from a command line by running RemoteMaster.jar with an argument -rm and RMPB with an argument -pb. Please note that although it is optional to run Setup.vbs in Windows as RMIR, RMDU and RMPB can always be opened in these ways, in Linux you need either to run setup.sh or to use some other means to add your user id to the dialup group of users. This need only be done once ever, however, as it is a system setting that is not specific to the RemoteMaster program.

When using XSight remotes (and similar ones such as Nevo) with Windows 8.1 or later, Enhanced Power Management needs to be disabled for access to the remote through the USB port. Changing this setting affects only the connection for that specific remote, leaving other devices accessed through USB ports unaffected. RMIR v3.0 checks for this and displays a message giving instructions for disabling it if it finds that this setting is still enabled.

RMIR is available only as a Java file and from version 2.09 onwards has required a Java 8 or later runtime environment, either 32-bit or 64-bit. Versions from 2.04 through 2.08 required Java 7 or later, version 2.03 and earlier only required Java 6. The release package includes the following support files:

• DecodeIR v2.45 as library files for Windows (32-bit and 64-bit), Linux and Mac OS X.
• jp12serial v0.33 as library files for Windows (32-bit and 64-bit), Linux, Mac OS X and Raspberry Pi.
• digitmaps.bin with digit maps up to number 767.
• protocols.ini which is a database of protocol executor data.
• RMIR.sys that contains the data needed by RMIR to perform firmware upgrades of the XSight remotes.
• The RDF File Specification, Version 4.
• The RDF File Specification, Version 5 as revision 18 of an Addendum to Version 4.

An update to any of these files will result in a new build being released, so there is no need for separate updating of any of them. Version 4 of the RDF File Specification covers RDF files for remotes with interfaces up to JP1.3. Version 5 is required to support remotes with interfaces from JP1.4 onward. Version 5 is under continuous review as UEI remotes with new features are discovered, with revisions of the Addendum being issued as required.

Please visit the JP1 Community Wiki for information about how to use RMIR. A link to the Tutorial in the Wiki is also included in the Help menu. Please note that as this project is supported solely by volunteers, the Wiki may not be up to date. However, RMIR shows notes and tooltips (the text shown when you hover the mouse pointer over a button or table entry) designed to make its use as self-explanatory as possible.

The download package is available in the following folder. Just click on it to start the download.

• http://sourceforge.net/projects/controlremote/files/RemoteMaster/v3.0.0 - (~30MB)

Please see above for installation instructions.

Links:
The RemoteMaster project home page.
IrpTransmogrifier manual.
JP1 Community Wiki
Tutorial (part of the Wiki)
Getting started with XSight and Nevo (also part of the Wiki)
Nevo and XSight Remotes (thread specific to these remotes)
Bluetooth is coming to RMIR (announcement thread for the new Bluetooth interface)
RF Support in RMIR (announcement thread for RF support through RF4CE)
jp12serial latest version (includes information on the various hardware interfaces supported by the jp12serial library)
Delcom and Prolific on Windows 10 (among other things, how to use a Delcom cable for JP1 remotes with Windows 10)
RMIR XSight Support (development thread)
RemoteMaster on Raspberry Pi with Raspian (development thread)
IrpTransmogrifier: new program/library for IRP protocols (development thread for IrpTransmogrifier)
Guide to Java Versions and Features (guide to the recent changes in Java availability)
How to install Java 8 on Windows XP (YouTube video and written instructions)
RM/RMIR v2.14 available (announcement thread for last official version)

[mathdon]

RMIR v3.0.0 includes a major restructure of the support for Key Moves, Macros, Special Functions and Learned Signals that affects all remotes. The most visible feature of this is the creation of "traffic light" highlighting to identify conflicts between entries in these tables. This would not have been possible before this restructuring. It is as follows.

• * Pink/Red highlighting identifies an entry for the same device and key as an earlier, unhighlighted, entry in the same table, so it could never be active in the remote. Such entries are not uploaded to the remote.
  
  * Yellow/Brown highlighting identifies an entry for the same device and key as an entry in a different table. All matching entries are highlighted and all are uploaded to the remote, though only one can be active. Which one will be determined by the operating system of the remote. The highlighting is intended as a warning, to allow the user to select the one to be active by deleting the others.
  
  * Green/Olive highlighting identifies a device-independent entry on the same key as as device-dependent entry in the same or a different table. Both are uploaded to the remote and both will be active, but the device-dependent one will take precedence when that device is selected. The highlighting is for information only, to notify that the device-independent entry will not work as expected on certain devices.

In the color pairs, the first color is that of an unselected cell, the second is that for a selected cell. The reason for two colors is that the foreground text of an unselected cell is Black, that of a selected cell is White, so a darker color is needed for contrast when selected. The "same device" here includes the case where both entries are device-independent.

An improvement that applies to all remotes that support more than one type of macro (normal, multi, realtime or controlled) is that the Macros tab has a new column that gives the type of each macro. On keys that support both normal macros and multimacros, it is now possible to create either type. On earlier versions a normal macro on such a key would be created as a multimacro with a single entry. There is no difference in behaviour between these on most remotes, but it is significant for certain remotes.

Many other improvements are internal, with either no, or only minor, changes to behaviour. Generally, more complex remotes are more affected by the restructuring than simpler ones. Near the top in the scale of complexity are the URC3660 and related remotes, the apex of complexity being the XSight remotes, especially the XSight Touch/Color. These remotes have a unique software structure, in that they store user data in a set of files rather than an EEPROM or a dedicated area of flash memory in their processor. The Raw Data tab of RMIR shows hex data in the same way as for other remotes, but this is in fact a concatenation of the binary data of the user files for these remotes. The mapping of this file data to RMIR structures has been revised to better correspond with the file structures. In places this has led to additional facilites being supported in RMIR. For example, Favorites need no longer be all on the same device.

JP1.4 and later remotes have a segment structure to their data area that is shown the the Segment Editor of RMIR. This tab is hidden by default but is enabled by checking Show Segment Area in the Options > Advanced menu. This is a persistent option that is preserved between instances. RMIR v3.0.0 now has a corresponding tab that shows the user files of XSight Touch/Color remotes in a human-readable interpreted form. This too is hidden by default. It is enabled by selecting Show XSight user file data in the Advanced > XSight operations menu. This menu item is only visible when a setup for an XSight Touch or Color remote is loaded, but it is again a persistent option, so that this tab will be present whenever such a setup is loaded or downloaded. A screenshot showing the form of this display is here in the Nevo and Xsight Remotes forum.

[davecs]

As we say in East London: Graham, mate, you're the dog's bollocks!!

(For those unfamiliar with British-English slang, that's about the ultimate compliment.)

EDIT: For some reason, the "i" in compl-i-ment gets changed to an "e" by this site. But I definitely meant with an "i".

EDIT2: But The Robman fixed it!

[The Robman]

EDIT: For some reason, the "i" in compl-i-ment gets changed to an "e" by this site. But I definitely meant with an "i".

There's a whole list of words that are commonly misspelled that the forum corrects, just to make things easier to read for folks, "the" is often written as "teh", "discrete" is often written as "discreet" or 'discreat", etc. And 99% of the time when people want to use the word "complement" here they are referring to 1s and 0s, it's rare for them to actually mean "compliment". But there are little hacks that you can do when you need to force it to the "other" spelling, edit your last post to see how I fixed it.

[davecs]

There's a whole list of words that are commonly misspelled that the forum corrects, just to make things easier to read for folks, "the" is often written as "teh", "discrete" is often written as "discreet" or 'discreat", etc. And 99% of the time when people want to use the word "complement" here they are referring to 1s and 0s, it's rare for them to actually mean "compliment". But there are little hacks that you can do when you need to force it to the "other" spelling, edit your last post to see how I fixed it.

But it let me have "dog's bollocks!"

[The Robman]

But it let me have "dog's bollocks!"

But people don't generally mistype "dog's bollocks!", if we were to get a lot of people referring to the "dog's bullocks!" I might have to add that to the list, lol.

I have some in there converting "remtoe" to "remote" and "protocal" to "protocol", as those are also really common.

[n8nagel]

this thread is getting ducking ridiculous!

Seriously, looking forward to playing with the new version. I should have the remote for my latest acquisition on Saturday, so you know what I'll be doing...

[The Robman]

this thread is getting ducking ridiculous!

Now I need to add "ducking" to the list.

[NOAMattD]

"discrete" is often written as "discreet"

I need some discreet codes for certain apps and websites...

Thank you for all your hard work as always Graham. I suspect there are many like me that rarely post here but benefit daily from your efforts in maintaining RMIR.

[jmezz13]

Excellent work Graham. Thanks for doing this!

BTW, I just looked up the word bollocks and I'll have to take davecs's word that "dog's bollocks" is a good thing. It's amazing how slang gets accepted sometimes....

[davecs]

Excellent work Graham. Thanks for doing this!

BTW, I just looked up the word bollocks and I'll have to take davecs's word that "dog's bollocks" is a good thing. It's amazing how slang gets accepted sometimes....

If something is very good, we used to say "It's the business". Later people used to say "It's the bee's knees". I suspect that "dog's bollocks" somehow came from that, though some people now say "mutt's nuts". But believe it or not, all these terms are extremely complimentary in Britain.

Strangely enough, if we say something is "bollocks" it means it's rubbish, or untrue, nonsense, etc. But if we precede it with "the", i.e., "the bollocks" it means the opposite. Vulgar (in the literal sense) language can be very interesting and contradictory.

EDIT: "complimentary" wasn't changed!!

[The Robman]

Strangely enough, if we say something is "bollocks" it means it's rubbish, or untrue, nonsense, etc. But if we precede it with "the", i.e., "the bollocks" it means the opposite. Vulgar (in the literal sense) language can be very interesting and contradictory.

I'd never thought about it like that, but it's true. However, like any language rule, it never holds 100% because I can think of an example where "the bollocks" still means rubbish. The album title "Never Mind the Bollocks here's the Sex Pistols" means, pay not attention to all the rubbish bands, here's the band you need to be listening to".

[n8nagel]

Excellent work Graham. Thanks for doing this!

BTW, I just looked up the word bollocks and I'll have to take davecs's word that "dog's bollocks" is a good thing. It's amazing how slang gets accepted sometimes....

If something is very good, we used to say "It's the business". Later people used to say "It's the bee's knees". I suspect that "dog's bollocks" somehow came from that, though some people now say "mutt's nuts". But believe it or not, all these terms are extremely complimentary in Britain.

Strangely enough, if we say something is "bollocks" it means it's rubbish, or untrue, nonsense, etc. But if we precede it with "the", i.e., "the bollocks" it means the opposite. Vulgar (in the literal sense) language can be very interesting and contradictory.

EDIT: "complimentary" wasn't changed!!

Here in the YooEss, you can say the same about "s**t". A Yugo is s**t, but a Miura SV is definitely the s**t.

[davecs]

I think the reason that the discussion here is so trivial (and fun!) is that there's nothing to say about the new release! We did it to death during the testing phase (2.15.x) and with 3.0.0 everything just seems to work! Not that it didn't before, but the 3660-family and xsight stuff is major.

I'd never thought about it like that, but it's true. However, like any language rule, it never holds 100% because I can think of an example where "the bollocks" still means rubbish. The album title "Never Mind the Bollocks here's the Sex Pistols" means, pay not attention to all the rubbish bands, here's the band you need to be listening to".

In the 1970s, you wouldn't have said "the bollocks" for something good. That emerged later. But I'm sure there are examples, though. Context is everything.

Anyway, whatever your choice of phrase, Graham deserves praise at the extreme complimentary end!

[The Robman]

Hi Graham, I just downloaded v3 to give it a whirl and unfortunately, I can't open the RMDU file that I was working on using it. So I have loaded the rmaster.err file for you.

http://www.hifi-remote.com/forums/dload ... e_id=26752

The rmdu file is here:
http://www.hifi-remote.com/forums/dload ... e_id=26743

Update: I've done some more testing and have concluded that it has to do with the ARRX15G XSight 15 that was selected in that upgrade, because even if I create a brand new upgrade using v3, if I select that remote, it won't be able to open it again. So I went back to the original upgrade (using v2.14.18) and changed the remote to one of the Atlas remotes and saved it, then tried opening it using v3 and it opened just fine.