JP1 Remotes

[mr_d_p_gumby]

[mr_d_p_gumby]

[mathdon]

[Mark Pierson]

[gfb107]

Graham,

I completely disagree with putting true/stock device specific Macros on the Special Functions tab. If the remote manual calls them Macros, they should be on the Macros tab. Otherwise it'll be confusing to typical users. There's nothing "special" about DSMs when they are a standard feature of a remote. They are a powerful and welcome feature, but not "special".

Additionally, the user should be able to change a true-DSM to a normal Macro (and vice versa) easily. And the macro shouldn't move from tab to tab in the process (or after upload/download). The way I see it, that means adjusting the Macro tab (and Macro dialog) dynamically to include the selected device button when the remote supports true/stock DSM, and hiding the selected device button when the

Special Functions (DSM or other), on the other hand, are an advanced concept by their very nature. It is clear that they provide function that is not a standard feature of the remote. This is further driven home to the user because they require installation of either an extender or a Special Protocol.

Don't worry, I'm not going to ask that the RDF 4 changes to support Internal Special Protocols be removed. It's too late for that, but I don't think it was the right way to go.

It is true that the approach used by the 6131 extender to use a hard-coded setup code and PID for DSM could create a conflict with a built-in setup code and/or PID. However, the choice of setup code and PID can be tailored to a specific remote (and even extender version), to ensure there is no conflict. Only the RDF and extender itself would have these values coded in them.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[mathdon]

It seems we can't agree to disagree, so I'll just make a few more points and then shut up on this issue.

1) Your approach would put the same functionality on two different tabs, depending on whether it is native or added (in the traditional way with a device and PID) via an extender. IMHO that is a confusion for anyone, not just a newbie.

2) At present, a Keymove can clash (ie same device and button) with an entry on the Special Protocols tab but at least the user doesn't have to check the Macros tab for a possible conflict. A Keymove can clash with a DSM, though, so you would add another tab that needs to be checked.

3) The name Special Protocols is unfortunate. It conveys absolutely nothing about their purpose, only about their implementation. Something like "Other Functions" would be better, IMHO, but "Special Protocols" is ingrained the JP1 psyche and clearly impossible to change.

4) Re Mark's point, Timed Macros are Macros too, but they have their own tab as they, like DSMs, need a different user interface.
_________________
Graham

[mathdon]

[gfb107]

This will also be my last post on the matter.

In your approach, any remote that supports native/internal macros must put ALL macros on the Special Protocols (Special Functions in RMIR) tab, because the only difference between a global macro and a native DSM is the device index: $f=global, anything else is DSM. The UI must provide a way to easily switch a macro to a DSM and vice versa. So for these remotes the Macro tab will always be empty, and shouldn't be shown at all.

In my approach, DSMs will be moved to the Macro tab, mixed in with the global macros. A column is added to show the associated device button (or All for global macros). Also the Macro create/edit dialog gets a drop-down box allowing the user to set the associated device button (or All for global macros).

Obviously the UI elements pertinent to DSM won't be shown for remotes that don't support DSM.

This would hide the difference between internal/native (macro encoded) DSM and Special Function (key move encoded) DSM. The only difference to the user would be the need to install an extender or device and protocol upgrade to enable DSM for remotes that don't natively support them. For remotes that use key move DSM, the tools should automatically encode as a macro when it's global, or as a key move when it's device specific. For remotes that use macro DSM, the tools should encode as a macro whether it's global or device specific.

We'll just add this to the list of significant philosophical differences between IR and RMIR.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[gfb107]

v1.98beta4 has preliminary support for multi macros. The sequence number is determined by the order of macros assigned to a multi macro button. The device index is set to $F. The next index is set to 1. For your sample file, this is different than what was dowloaded from the remote. There is no checking to limit the number of macros assigned to any button.

It is also different than what IR does, which surprised me given the discussion we had about how IR handles multi macros.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[wnewell]

Are you saying 1.98b4 should work with the macros of the RCRP05B RCA remote? If so, I'll give it a test.

[gfb107]

Yes, but you must add the [MultiMacros] section to the RDF as described by binky earlier. Make sure you add it after the [Buttons] section
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)

[wnewell]

I added the multimacros lines to the rdf. Then using 1.98b3 did a download and upload to the remote and the macros still worked. I then reset the remote with 980 so the macros were gone and then did another upload. The macros were not there. So, it appears with the modified RDF 1.98b3 doesn't overwrite any existing macros,but also won't upload them.
I then upgraded to rm 1.98b4. It was totally wacked. Device types, setup codes, and other setting on general tab changed when changing tabs. No matter what I tried, I couldn't get that to work. However, it did appear that macro 1 did work, and macro2 worked, but only in cable mode. That was probably because in the DVR mode in the main settings were screwed up. So basically I had to go back to 1.98b3 to get my remote working right again.

[gfb107]

I see the problem.

There must be a mistake in the [MultiMacros] section Binky suggested:

[mdavej]

wnewell,

If binky doesn't already know, you can find the right values to put in the RDF. Manually program a macro on Macro1 and see what changes in the raw data. The first byte that's different (besides the check sum bytes at $608 and $609) is the one we're looking for. Repeat for the other multimacro buttons. I'm guessing they're somewhere in the neighborhood of where they are in the 15-135, which is $623. That ends up being $23 in the RDF when you subtract the BaseAddress offset of $600.

[gfb107]

I've not been able to figure it out, but I suspect that with a little bit of manual work on the remote you can help me get the information I need.

Here's what I'd like you to do:

1. Remove the newly added MultiMacros section from the RDF, so that IR/RMIR won't try to interpret/update the bytes we're trying to find.
   
2. Reset the remote, download and save to a file.
   
3. Manually create multiple macros on each of the suspected multi-macro keys (Macro1, OnDemand, Macro2). Create a different number of macros on each, as we know the count gets stored in the multimacro bytes and that'll help us figure out which bytes go with each multimacro.
   
4. Download and save to a different file.
   
5. Upload those files to the diagnosis area and provide links
   

The only changes between the two downloads should be the created multimacros, so we'll be able to see exactly which bytes have changed.
_________________
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)