RMIR: Prototype IR function in RM

gfb107 · Post by **gfb107** » Tue Sep 12, 2006 7:47 am

Liz, RM v1.68 should address everything you have brought up.

Post by **ElizabethD** » Tue Sep 12, 2006 8:54 pm

It does.
Your speed and what it looks like surpasses all expectations

Big thanks for the filepaths and filedates. that'll help keep my notes honest and maybe unjungle my updates. Small item but hugely helpful. I'll be trying more as time permits.

Post by **ElizabethD** » Tue Sep 26, 2006 8:21 pm

Greg, will there be Extinstall function in RMIR? If it's there I don't see it but I don't expect it yet. This is not a nag post, believe me

just a question.
If yes, could you possibly not drop the Notes the way current Extinstall does in merging. The Notes preservation is already in RMIR, so it could carry over, I hope. It's a real pain to have to do the Notepad routine just to preserve the notes.

gfb107 · Post by **gfb107** » Tue Sep 26, 2006 9:39 pm

There will be, eventually. Of course I'll try to preserve notes.

Capn Trips · Post by **Capn Trips** » Thu Oct 26, 2006 3:14 pm

An observation/difficulty with RMIR. (Really in-the-weeds stuff here)

I occasionally build upgrades that EXACTLY replicate built-in Setup Codes and then create keymoves within that upgrade for advanced functions, assignments to phantoms, what-have-you. I then copy and paste the upgrade (which includes keymoves) into IR for the sole purpose of importing the keymoves. I then delete the device upgrade (because it exactly matches the built-in Setup Code) but KEEP the Keymoves.

The reason for this is it allows me have a Device Upgrade file that tracks for me where EVERY function of that device is mapped. I find it a convenient tracking tool.

In RMIR, the Keymoves associated with a specific device upgrade are automatically associated with that upgrade and REMAIN so associated, so I cannot selectively delete just the upgrade - the associated keymoves will always be deleted along with it.

Is there a way to provide for a "selection" of whether or not one wants the keymoves for a particular device upgrade associated with or "disassociated" from that device upgrade? If not, one (i.e. I) will be forced to manually build every keymove that calls on a built-in device setup code, rather than the shorthand I described above.

johnsfine · Post by **johnsfine** » Thu Oct 26, 2006 3:36 pm

That's in the weeds all right.

I wouldn't want to wreck or confuse a good feature (that IR lacks) to support that. But maybe there is an easy kludge.

Capn Trips wrote: The reason for this is it allows me have a Device Upgrade file that tracks for me where EVERY function of that device is mapped. I find it a convenient tracking tool.

That sounds a bit unsound. When assigning things on the buttons sheet, what happens if you want a different function on a button than the built-in has, but it is a button that could be built-in. Then the KeyMove will be missing.

Capn Trips · Post by **Capn Trips** » Fri Oct 27, 2006 7:26 am

Bottom Line Up Front: If this can be done relatively easily - perhaps "simply" (I realise that nothing is truly simple) via Advanced Menu button selection(s), I think it might be worthwhile to allow a user to DISASSOCIATE Keymoves and/or Protocol Upgrades from their associated Device Upgrades.

We could debate the soundness of what I'm asking for, or even what I'm doing, and perhaps I'm not describing adequately what I'm driving at and why. But that is really not germane to my request.

Let's just say for this discussion (which is, after all, simply a feature request, like others have come before and will likely follow) that I think this feature (REGARDLESS of my motivation) can be useful.

To wit, having the ability to DISSASSOCIATE a Device upgrade from its associated keymoves (e.g. to permit deletion of the Device upgrade without deleting its associated Keymoves).

Similarly, I would like the ability to delete a Device Upgrade-associated Protocol upgrade without having to delete the associated Device upgrade. THIS capability has a VERY REAL consequence for me in the following circumstance.

RM support for the Sharp DVD and other related Kaseikyo-family protocols is incomplete/incorrect/immature (choose your euphemism). This is due to different executors being used in different remotes for the same protocol and RM not properly reflecting these.

Specifically (as I have raised several times in these fora, likely ad nauseam), for the 8910/9910/HTPro remotes, the built-in Sharp DVD executor appears to be 0171, YET, when I build the upgrade in RM, it uses executor 00F8 - REQUIRING A PROTOCOL UPGRADE! Since RM does not allow me to change the protocol to 0171 (without introducing a bunch of fields that are inscrutable to me), the workaround I have developed is to build the upgrade in RM and only copy the Device Upgrade into IR, leaving the Protocol upgrade behind.

I then EDIT the device upgrade in IR to call on executor 0171 vice 00F8. I cannot do this in RMIR, since it automatically cascades down into the Device upgrade sheet, making it once again inscrutable. So for my Sharp DVD player upgrade, I am better served by having the Protocol upgrade DISASSOCIATED FROM the Device Upgrade.

I would wager that there are other such circumstances in which one would benefit from the ability to keep the Device and Protocol upgrades distinct from one another, particularly as one tweaks newly-discovered or analysed protocols.

gfb107 · Post by **gfb107** » Fri Oct 27, 2006 8:03 am

Capn Trips wrote:RM support for the Sharp DVD and other related Kaseikyo-family protocols is incomplete/incorrect/immature (choose your euphemism). This is due to different executors being used in different remotes for the same protocol and RM not properly reflecting these.

Specifically (as I have raised several times in these fora, likely ad nauseam), for the 8910/9910/HTPro remotes, the built-in Sharp DVD executor appears to be 0171, YET, when I build the upgrade in RM, it uses executor 00F8 - REQUIRING A PROTOCOL UPGRADE! Since RM does not allow me to change the protocol to 0171 (without introducing a bunch of fields that are inscrutable to me), the workaround I have developed is to build the upgrade in RM and only copy the Device Upgrade into IR, leaving the Protocol upgrade behind.

I then EDIT the device upgrade in IR to call on executor 0171 vice 00F8. I cannot do this in RMIR, since it automatically cascades down into the Device upgrade sheet, making it once again inscrutable. So for my Sharp DVD player upgrade, I am better served by having the Protocol upgrade DISASSOCIATED FROM the Device Upgrade.

I would wager that there are other such circumstances in which one would benefit from the ability to keep the Device and Protocol upgrades distinct from one another, particularly as one tweaks newly-discovered or analysed protocols.

Instead of adding code to allow users to workaround bugs, let's just fix the bugs. I guess I haven't seen (or just don't remember) the discussions about the problems with Sharp DVD and other related Kaseikyo-family protocols.

Can you provide a link to any discussion about this, so we can fix the root problem?

johnsfine · Post by **johnsfine** » Fri Oct 27, 2006 8:23 am

I agree we ought to fix whatever errors in protocols.ini are creating that Sharp DVD confusion. Maybe even improve RM's ability to be led (by protocols.ini) through the tangle of related protocol names intersecting related PIDs.

But Capn Trips also made good points regarding the ability for experts to sidestep the rules.

The lack of integration between KM and IR has been a long term significant pain. But it also has allowed some cute tricks, such as Rob just used in his recent thread using an experimental modified NEC executor.

As we connect RM and RMIR, so the ordinary user won't even need to know there are rules, we should still give expert users some way to break the rules.

Capn Trips · Post by **Capn Trips** » Fri Oct 27, 2006 8:26 am

I first reported it HERE,

and tried to resurrect it HERE. I'll give that thread a bump to see if other experts notice it.

I've tried to not be a PITA, harping on this thing continuously since I know you guys have lives, and as long as I have a workaround, I'm happy.

There are not only RM issues here, there are DecodeIR.dll issues, KM support is incomplete with respect to this Protocol/Executor family, on and on.

As for the feature request - I was providing the SharpDVD/Kaseikyo 00F8/0171 thing as an example where the feature would make life easier for a user, so I still contend there are times, perhaps currently unforseeable times, when the "Disassociate" feature will be worth having, regardless of this particular example with the Kaseikyo-family Protocols/Executor getting properly sorted.

Post by **ElizabethD** » Fri Oct 27, 2006 1:11 pm

Capn Trips wrote:Let's just say for this discussion (which is, after all, simply a feature request, like others have come before and will likely follow) that I think this feature (REGARDLESS of my motivation) can be useful.
To wit, having the ability to DISSASSOCIATE a Device upgrade from its associated keymoves (e.g. to permit deletion of the Device upgrade without deleting its associated Keymoves).

Similarly, I would like the ability to delete a Device Upgrade-associated Protocol upgrade without having to delete the associated Device upgrade. THIS capability has a VERY REAL consequence for me in the following circumstance.

Me thinks so too

If some switches could be added, without burdening the users with endless decisions, it would be cool. It may not be needed in common use, but when you need it, you REALLY need it.

Post by **ElizabethD** » Fri Nov 24, 2006 9:01 pm

I gather that v1.69 can now download from the remote, right?
I tried it, but it says "no response from the remote". I then downloaded the latest version of Decode_IR (2.32?) and unzipped it into the RM 1.69 directory. Is that the expected place? Whatever, still no response from 8910.

Capn Trips · Post by **Capn Trips** » Sat Nov 25, 2006 4:32 am

Liz, as I understand from a read of the entire thread, I believe RMIR at this time can only communicate with JP1.x remotes, not the JP1's yet.

gfb107 · Post by **gfb107** » Sat Nov 25, 2006 8:31 am

Capn Trips wrote:Liz, as I understand from a read of the entire thread, I believe RMIR at this time can only communicate with JP1.x remotes, not the JP1's yet.

Correct.

Post by **ElizabethD** » Sat Nov 25, 2006 8:58 am

That occurred to me after I posted. It's just that at this point I can't be 100% sure which info in this thread still applies. Also I haven't read this thread lately