JP1 Remotes

ElizabethD wrote:Nice additions

(6)
- With "READ THE ASSOCIATED README, BUT...." suggest to read for logic and how all those SP keymoves are built by writing hex commands, but add a reminder that with the Special protocols, all the hex commands are made by IR while we pick and choose the keys. There is a reference elsewhere to that, but a short repeat might be a good idea here as well.
- Start of the 3rd paragraph - insert "TV/1800" before "DO NOT DELETE THIS DEVICE AND PROTOCOL UPGRADE!"

6a-Device Multiplexer.
Perhaps add about limitation of how handles keymoves. If I recall correctly, only one set of keymoves can be made (at least in 8910). But I really don't remember the details. I once asked Rob, but can't find the post, and then there were others about newer remotes, and a thread suggesting "dynamic keymoves" for multiplexing.

I tried to add changes for the clarifications you seek.
(1) First mention of "DO NOT DELETE" was originally immedately after the paragraph that ended with TV/1800 and Protocol 0180 but had since been separated by additional inserted text;
(2) Not sure what you intend with the Hex command reference, but I'm not sure getting into too much detail helps the user, especially if the tools make it transparent. Please take a look at my brief mention of Hex;
(3) As for internal logic, I suffer from being too close to the document, so it looks fine to me. If you can re-phrase/re-write some section, please do and I'll replace it with your clearer wording.
(4) Having never used Device Multiplexer successfully, so although I understand that the associated keymoves don't shift with the device selection, I'm again not sure that mention of that here serves to clarify, but perhaps to obfuscate. Suggested text is welcomed

3FG wrote:Please consider this alternate phrasing:

6a-Device Specific Macro: Allows you to create a macro which will only be called if the remote is in the specified device mode (e.g. TV or CBL). Ordinary macros are called whenever the assigned button is pressed, regardless of the current device mode.

Adapted and inserted.

Capn Trips wrote:I tried to add changes for the clarifications you seek.
(1) First mention of "DO NOT DELETE" was originally immedately after the paragraph that ended with TV/1800 and Protocol 0180 but had since been separated by additional inserted text;
(2) Not sure what you intend with the Hex command reference, but I'm not sure getting into too much detail helps the user, especially if the tools make it transparent. Please take a look at my brief mention of Hex;
(3) As for internal logic, I suffer from being too close to the document, so it looks fine to me. If you can re-phrase/re-write some section, please do and I'll replace it with your clearer wording.
(4) Having never used Device Multiplexer successfully, so although I understand that the associated keymoves don't shift with the device selection, I'm again not sure that mention of that here serves to clarify, but perhaps to obfuscate. Suggested text is welcomed

1-ok, that's what I thought might have happened
2-The problem is that various old extender instructions show how to make the keymoves the hard way. I did read your thing, of course. But newcomers read the readme and think it's inconsistent with IR.
3-no, leave things alone. I can't think actually how to do it better
4-ok, skip it, since I'm fuzzy on multiplexer as well.

ElizabethD wrote:

Capn Trips wrote:I tried to add changes for the clarifications you seek.
(1) First mention of "DO NOT DELETE" was originally immedately after the paragraph that ended with TV/1800 and Protocol 0180 but had since been separated by additional inserted text;
(2) Not sure what you intend with the Hex command reference, but I'm not sure getting into too much detail helps the user, especially if the tools make it transparent. Please take a look at my brief mention of Hex;
(3) As for internal logic, I suffer from being too close to the document, so it looks fine to me. If you can re-phrase/re-write some section, please do and I'll replace it with your clearer wording.
(4) Having never used Device Multiplexer successfully, so although I understand that the associated keymoves don't shift with the device selection, I'm again not sure that mention of that here serves to clarify, but perhaps to obfuscate. Suggested text is welcomed

1-ok, that's what I thought might have happened
2-The problem is that various old extender instructions show how to make the keymoves the hard way. I did read your thing, of course. But newcomers read the readme and think it's inconsistent with IR.
3-no, leave things alone. I can't think actually how to do it better
4-ok, skip it, since I'm fuzzy on multiplexer as well.

2 - I tried to address this in the opening of (6a);
4 - I gave it a shot, perhaps it could be clearer?

Capn Trips wrote:2 - I tried to address this in the opening of (6a);
4 - I gave it a shot, perhaps it could be clearer?

2-ok, it's sufficient
4-better wording than I would've thought of

ElizabethD wrote: 4-better wording than I would've thought of

Ditto that. Capn_Trips is a master of clear communication.

Suggested diffidently--maybe I'm confused, but we don't really upload RDFs to the remote. Item (7):

When you have built your extender .ir file in IR and you upload it to your remote, you will receive a pop-up window alerting you about mismatched rdfs. That is expected, as you are uploading a DIFFERENT rdf to the remote that supports the extender. Just accept the overwriting of the original rdf.

Possible change to the italicized section:
Each model of remote has a signature, and IR checks to see that the RDF file in use matches the signature. When an unextended remote is loaded with an extender, the signature is intentionally altered, causing a one-time mismatch between the remote's signature and the signature in the ir file. Just accept the upload.

vickyg2003 wrote:

ElizabethD wrote: 4-better wording than I would've thought of

Ditto that. Capn_Trips is a master of clear communication.

Huh?! What the...? Oh, yeah - like what SHE said ... I guess. Totally.

3FG wrote:Suggested diffidently--maybe I'm confused, but we don't really upload RDFs to the remote. Item (7):

When you have built your extender .ir file in IR and you upload it to your remote, you will receive a pop-up window alerting you about mismatched rdfs. That is expected, as you are uploading a DIFFERENT rdf to the remote that supports the extender. Just accept the overwriting of the original rdf.

Possible change to the italicized section:
Each model of remote has a signature, and IR checks to see that the RDF file in use matches the signature. When an unextended remote is loaded with an extender, the signature is intentionally altered, causing a one-time mismatch between the remote's signature and the signature in the ir file. Just accept the upload.

Jeez-Lou-eeeze! Nobody looks at this thread for almost a YEAR and suddenly NOW everybody's a critic!

If your comment wasn't a VALID one, I'd be offended that you DARE to offer a correction, but seeing as how you're correct - I have made the edit.

"Language is the most important... uh... I think you know what I'm trying to say here"
- Steve Martin, ca. 1977

Capn Trips wrote:Comments/corrections/fixes are welcome.


Device Multiplexer: Allows you to stack two devices on a single button, and with a button press, change the assigned device on, say, your "DVD" button from your Pioneer DVD recorder to your Sony Blu-Ray player. It's most useful on remotes that do not have enough Devices for your HT system setup. WARNING: New versions of KM, RM, IR, and RMIR make it transparent whether particular functions are assigned directly to buttons within the body of an upgrade or keymoves created automatically by the software. When you use Multiplexer, however, only a SINGLE keymove can be assigned to any button for that device, so you must be careful that you do not inadvertently try to "double-stack" keymoves on the same buttons because only one set will be active, regardless of which multiplexed device you have selected

I really felt that WARNING was too strong a word for this, and when I tried to read the warning it was a little over my head.

I'd suggest something more like this

Device multiplexers merely change the setup code, the keymoves remain static. Therefore special consider need to made when constructing upgrades in RM or KM to make sure that there will not be a conflict in functions that end up as keymoves. In general all shifted buttons, xshifted buttons will be keymoves. With plain buttons that start with a @ in KM or end with a * in RM will be keymoves.

And then of course my new extenders are going to have additional considerations, since I am using dynamic keymoves, but for that they can just read the readme.

Device Multiplexer: Allows you to stack two devices on a single button, and with a button press, change the assigned device on, say, your "DVD" button from your Pioneer DVD recorder to your Sony Blu-Ray player. It's most useful on remotes that do not have enough Devices for your HT system setup.

This is just a comment, not a suggestion for a change, but I use Device Multiplexer to emulate the zone-switching capability of my Onkyo AV Receiver. The OEM remote has a button to switch between Zone 1 and Zone 2. The effect on the IR signal is that it changes the device code in the fixed data. Device Multiplexer can be used to do exactly that. So it has uses for a single "physical device", not merely to get over a shortage of device buttons.

Added a Note to FAQ 8 in light of this thread.

A few other minor tweaks to the FAQ, primarily to attempt to treat the JP1.x (FLASH) type remotes as more common rather than the JP1 (EEPROM) remotes which are growing scarcer and scarcer, and to address minor inaccuracies brought to my attention.