RMIR v2.15.0 pre-release for testing

[HamburgerHelper1]

It appears that Multi Macros will work on the App keys but more testing needed
I think these were tested earlier with a previous version of the RDF and RMIR and they did not work, but with newer versions and by temporally deleting
RealTimeMacroData=$2D $2E $2F, $74 $75
MacroSupport=3
and adding app 1 2 and 3 to the [MultiMacros section My multimacros are working
The behavior of the key is that you must hold the key for about 3 second then release
and the macro's will run when the key is released

[davecs]

For any one Testing with the URC-3660/61/68
I suggest for background info you read the thread "New Remote URC-3660"
This lengthy conversation is the development of the 3660 RDF
and Mathdon's explanations will give you insight as to what was tested
and how things work.
Matrhdon's hard work and explanations might help you in your endeavor of more testing.
I know it helped me

"New Remote URC-3660"

http://www.hifi-remote.com/forums/viewt ... highlight=

Randy

I had read through this thread before, but having taken part in this testing, I think I understood it much better this time. Thanks for the nudge!

[mathdon]

I have replaced RMIR v2.15.4 in the RMIR Development folder with v2.15.5. This includes significant updates to v2.15.4, the main ones being:

• * The 64-bit versions of jp12serial have been updated from v0.32 to v0.32a, a release candidate for v0.33. This fixes the issue causing verification failure when uploading to a JP1 remote.
  
  * There is a new option on the Advanced menu, "Disable Upload Restrictions". This allows creation of macros and special functions with bound buttons that are otherwise unavailable and disables clash highlighting so that all data is included in an upload. If this option is subsequently deselected while the setup contains such normally excluded entries, those entries will get a distinctive light purple highlighting, changing to dark purple when selected. They are then excluded from an upload but will be included in a saved .rmir file. This option is not persistent, it is deselected on every restart of RMIR.
  
  * If a setup for a JP1 remote is loaded or downloaded that contains any macros or special functions that exceed the size supported by these remotes, they are truncated to the maximum size and a message is displayed identifying the ones affected.
  
  * The handling of device-independence has been rationalized across its various uses in RMIR, which incidentally also fixes a few bugs.

I think this deals with all the actual bugs that have been reported, but does not take into account all the recent comments and findings. @jmezz13, I hope you will test loading the .ir file you posted that had the overlong special function, to see if you think the current fix is satisfactory.

I have been doing some testing with my URC-3660 after creating a fairly complicated setup file and cannot reconcile the file data with how the remote behaves, so I have not made any changes to the RDF for this and the related remotes. I suggest that when you do further testing with the 3660 or 3661, you leave the RDFs unchanged and select the new "Disable Upload Restrictions" option instead. That is what I have been doing, and it will allow you to create pretty much anything you may want to test.

I hope you all are using 64-bit Java, but suggest that you do check the Help > About menu to make sure that the jp12serial version being used is v0.32a, not v0.32. If it is not, then do let me know.

Just to say that when I use the URC6440 and OARUSB04G, set up as per the thing I put in the wiki in 2019, RMIR autodetects the remote. Before, if I had previously used a JP1.x remote, I had to type in the path to the USB remote, but now I don't have to. Was that your handy-work?

It isn't anything I have recently done, but that is how it is supposed to work. Perhaps a recent change has sorted something that was preventing it working for you.

[jmezz13]

The customer service is amazing around here!

[jmezz13]

I can report that with 2.15.5, the upload error on verification that I was experiencing prior with EEPROM adapter appears to be resolved.

Regarding the setup with the overly long 18-byte special function. It uploads and even downloads without error which is great. However, the 8811 remote does not work properly in this case. @mathdon - you had mentioned you weren't sure if the extender would be able to handle to extra bytes in the special function and the answer appears to be no. Not sure if there is a need for a warning (maybe highlighting the special function) to user as it seems to have only been reported by me(?). Edit: Now that I read your message again, I see this has already been addressed. Perfect!

Now I should probably do some more testing with the 3660....

[davecs]

The customer service is amazing around here!

Sure is!

[davecs]

I had to wait for the TV again after my last post...

Anyway, this is what I found with the 3661:

I disabled upload restrictions and added two "illegal" Special Functions:

1. A RealTime Macro on Blue — and guess what? It worked perfectly!

2. A MultiDSM on App1 — Strange one, this. As HH1 found when he hacked the RDF yesterday, it works, but differently to other keys. A short press still got the basic function assigned to that key. However, on a long press, the signal of the MultiMacro was not sent until I released the key. There could be a use for this, not sure what it is, but it does show that it works.

I enabled upload restrictions so that the two lines appeared in purple. And the remote behaved exactly as it did before I added them. In other words, it successfully blocked them from the upload.

There has been no regression on the other features Graham has added, and the option to disable Activities is brilliant!

As for the 6440:

I deleted one of my Global special functions, then put it back in from scratch, and the <none> did appear at the start of the line this time. And no issues uploading to or using the remote.

As far as the RMIR program is concerned, a great success! However, it seems that assumptions have been made in the RDFs for the 3660/1/80 family of remotes, based on early experimentation, which have turned out to be wrong. But RDFs can be updated separately from the RMIR program.

[jmezz13]

I did some more testing with 2.15.5 and the 3660. Basically, I tried all 6 types of macros with the following types of buttons:
1) Activity
2) Power
3) App
4) Colored (multimacro)

So, just for documentation purposes, if I leave "Disable Upload Restrictions" unchecked, I find the following actions are not "allowed":

MultiMacros on App buttons
Real-time Macros on Colored Buttons
MultiDSM on App buttons
Real-time DSM on Colored buttons

I think this is all as expected. I did notice that RMIR allows me to select invalid combinations if I just edit an existing Special Function. For example, if I create a Real-time DSM on an allowed key, but then edit the Special Function, it allows me to select a Colored button, but does show the entry in a pink(?) color. It does not seem to restrict the button selections in the same way as when a Special Function is created.

I also ran into an issue where a Macro conflicted with a specific Key Move (that is not part of a device upgrade) on that same button for one device. In that case, the Macro worked as expected on that button except when that specific device mode was active in which case it would execute the Key Move. I'm not sure that is as intended, but wondering if it would make sense to color the macro entry brown (like it does for Special Functions) to notify the user that there is a potential conflict in at least some device modes. I was expecting the Macro to take precedence in every case, like it does with normal button assignments in device upgrades.

[davecs]

I also ran into an issue where a Macro conflicted with a specific Key Move (that is not part of a device upgrade) on that same button for one device. In that case, the Macro worked as expected on that button except when that specific device mode was active in which case it would execute the Key Move. I'm not sure that is as intended, but wondering if it would make sense to color the macro entry brown (like it does for Special Functions) to notify the user that there is a potential conflict in at least some device modes. I was expecting the Macro to take precedence in every case, like it does with normal button assignments in device upgrades.

Yes, and on the 3660/1 family, we've already established that a multimacro on an "internal key move" caused by Volume punch-through also conflicts. We might want to take a look at whether internal key moves caused by Activities are affected. Whether anything can be done if they are, is one thing. But maybe we can put some kind of manual together for these remotes as its possibilities are quite complex.

[mathdon]

For example, if I create a Real-time DSM on an allowed key, but then edit the Special Function, it allows me to select a Colored button

Thanks for pointing this out. It was due to a simple typo in the code and is fixed for the next build.

I also ran into an issue where a Macro conflicted with a specific Key Move (that is not part of a device upgrade) on that same button for one device. In that case, the Macro worked as expected on that button except when that specific device mode was active in which case it would execute the Key Move. I'm not sure that is as intended, but wondering if it would make sense to color the macro entry brown (like it does for Special Functions) to notify the user that there is a potential conflict in at least some device modes.

It is not what is intended, but it is how the remote works and that I have no control over. I think highlighting is not appropriate in this case as yellow/brown highlighting is intended to indicate that only one of the highlighted items will be active in the remote and the user should choose which one they want. In this case both items are active, even if they don't work together in the way that the user might expect, and so it makes sense to upload both.

This is only one of several odd behaviours in this rather complex remote. The behaviour of MultiDSMs on App keys that you (collectively) have recently found is another. The choice seems to be between preventing RMIR from creating these cases or allowing it and putting up with the behaviour. I think we should follow the latter. I can't see that it is the job of RMIR to explain every quirky behaviour in these remotes.

Edit: Davecs has just said "But maybe we can put some kind of manual together for these remotes as its possibilities are quite complex." I nearly suggested that, I think it is a very good idea.

Edit2: There are other cases of "partial conflicts" that we accept without comment. A macro on a key conflicts with a a DSM on that key for some specific device. The DSM takes preference on that device, the macro works on all other devices.

[HamburgerHelper1]

Since according to the user manual the color keys are MultiMacro keys designed for favorite channels, that operate when held for 3 seconds
and the App keys are for timed Macros
I can only assume that is why the app keys will activate a multimacro when held for 3 second and send signal when released
Considering we are doing something we are not supposed to be able to do
( at least without the aid of RMIR) Someone may find putting a MultiMacro on the App keys useful.

[mathdon]

I have now tried a number of combinations of normal, realtime and multi macros in both device-independent and device-dependent forms and all have worked as expected, bearing in mind one very important proviso. This is the action of the App keys. I think the following is what is happening with these keys.

An App key uses a long press to put it into progamming mode, so a signal requiring a short press, such as a real-time macro on it, will be sent on release of the short press as until the key is released, the remote does not know whether the press is going to be long or short. When a multimacro is put on an App key there are three timings involved: a short press, a longer press that activates the multimacro and an even longer one that enters programming mode. That it is one of the first two can only be determined on key release, which is why the multimacro is sent on release of a long press. The even longer press is never reached, so it never enters programming mode when there is a multimacro.

I believe the problem I was having yesterday in reconciling the data in my setup to the behaviour of the remote on an App key was due to inadvertently programming the key when testing what a long press did. So it sent the programmed data, not what my setup put on it. I had a setup that had a real-time macro on one App key and a multimacro on another. So one required a long press to send the signal, on the other a long press had to be avoided to prevent inadvertent programming. Terribly confusing.

I think there is sufficient danger of users doing the same thing that RMIR should not allow multimacros on these keys. I propose amending the RDFs for these remotes to allow real-time macros on the color keys but not multimacros on the App keys. Normal macros are already allowed on both. Does this meet with approval?

Edit: This crossed with HamburgerHelper1's post which has a similar interpretation of the behaviour of App keys.

[HamburgerHelper1]

I forgot about the Long Press to program the App keys.
I have run into difficulty with using MultiMacros on the App keys and perhaps, as Graham suggested, multimacros should not be permitted on them after all.

[HamburgerHelper1]

Before not permitting the App keys from Multimacros I tried to see if somehow nested Macros (one Macro calling another Macro) might work with the signal being sent when the key is released
No such luck
But an Idea if any one else wants to pursue it

[jmezz13]

I think there is sufficient danger of users doing the same thing that RMIR should not allow multimacros on these keys. I propose amending the RDFs for these remotes to allow real-time macros on the color keys but not multimacros on the App keys. Normal macros are already allowed on both. Does this meet with approval?

Edit: This crossed with HamburgerHelper1's post which has a similar interpretation of the behaviour of App keys.

Given all the capabilities we have with other keys including color keys and activity buttons, I would think it reasonable to limit multimacros on the App keys.