Experts please help: multimacros, device-mode macros

[mathdon]

Very quick response. $AF is a multimacro because the low nibble is $F. $AC is an internal special protocol because the low nibble is not $F. Ambiguity resolved. And remember that the flash is interpreted in the context of the RDF.

I don't have a remote with either multimacros or a Fav key, but they are certainly quite distinct objects in IR.exe.

Byte #1, the bound key in a macro, is the bound key also in an internal Special Protocol.

Internal special protocols are a new concept in RDF Spec 4. They are implemented as 'macros', in the same way that 'normal' special protocols are implemented as keymoves. The quotes round 'macros' means that the high nibble of byte #2 is a macro nibble, the distinction being made with the low nibble ($F for macros, anything else for internal special protocols). The Special Protocols tab in IR.exe now shows both types of special protocol.

Greg, sure, IR.exe and RMIR have to conform to what real remotes do. But JP1 takes advantage of things that are undefined in real remotes, otherwise there could be no such things as extenders and special protocols. So there IS a potential to differ. I was expressing the hope that it does not accidentally happen.

I was not aware of the existence of DSMs implemented natively in UEI remotes. There is no RDF entry for them, or any table they could appear in other than Special Protocols. They sound very much like the RDF Spec 4 concept of an internal DSM special protocol - in fact, I think they must be identical - and I see no reason why they could not be included in the RDF as an internal DSM special protocol. But internal special protocols are not restricted to be DSMs, any special protocol can be implemented this way. The advantage of an internal SP is that it does not need a device code or PID.

IR.exe has a limit of 5 for remotes with AdvCodeBindFormat= LONG, limit of 3 otherwise.
___________
Graham

[WagonMaster]

As you can tell from my questions in this thread, I don't have a grasp of all this either. And I've been around JP1 since 2002, working on RM & RMIR since 2003!

Well, maybe we can collectively "stumble around in the dark" long enough to eventually pin this down with enough inputs from various folks!

Assuming we do, I have no problem with "archiving" what we learn in this exercise with some documentation updates.

Bill

[WagonMaster]

Very quick response.

Thanks much for the info, Graham -- very helpful. I'll try to digest it some more with a bit more reading and testing too. Eventually I may be able to pretend to understand some of this JP1 macro/keymove stuff.

Bill

[binky123]

FavKey cycles thru all the FavKey entries until a key is pressed on the remote to stop the cycling. It is similar to a multimacro except that you press a button to stop whereas in a multimacro, you press a button to do the next entry.

[mathdon]

Does anyone involved in this discussion actually have a remote with native DSMs? If so, could they try putting this in the RDF:

Code: Select all

[SpecialProtocols]
DSM=Internal:0

This should give access to the native DSMs in the Special Protocols tab of IR.exe (version 8.00 or later). If there are such things as device-specific multimacros (DSMM ?), there is no equivalent for them.

BTW How do multimacros show up in IR.exe? There is no special page for them and, as far as I can see, nothing on the Macro page, either. Is it just a question of assigning more than one macro to a button that is listed in the [Multimacros] section of the RDF? If so, if DSMMs exist then it might be possible to support those in a similar way on the Special Protocols page.
_______________
Graham

[mathdon]

In an earlier post I wrote

Bill, how were you looking at the value of the low nibble of that 2nd byte? For remotes with AdvCodeBindFormat=LONG, such as the RS15-135, IR.exe sets it always to $F. According to notes in the IR.exe source code, this nibble is not used internally in remotes, except for one remote which requires it to be $F. (This pre-dates my involvement.) Because of the way IR.exe operates (as in previous posting), when you load a flash ROM you should see $8F there, even if it was, say, $81 in the flash.

Grovel grovel . I was wrong. If you create a macro with IR.exe (ordinary or multi), the low nibble will be set to $F, but if you create it in the remote and download to IR.exe then it leaves that nibble unchanged.

I've found I have a .ir file for an RS15-135 and have tried some experiments, even though I don't have the remote to test with. First, I've answered my own question - multimacros show up as multiple entries for the same key on the Macro page. With IR.exe as it currently is, if you add DSM=Internal:0 to the RDF as I suggested above, then if you create a DSM on the Special Protocols page it looks in Raw Data like I would expect a native DSM to look, ie like a macro but with the low nibble of byte 2 being the device code, not $F. Save the file and re-load it, and it returns properly to the SP page.

But then I tried the same thing with the multimacro key. I created two DSMs for the same device (TV) on this key (it allowed me to do so) and looked at the raw data. They were what I would expect for device-specific multimacros, the 2nd byte being $91 for the first and $A1 for the second. Do it with DVD instead of TV, get $93, $A3. But if you save the .ir file and re-load it, they have turned into ordinary macros. Still the same byte 2, but on the macro page, not the SP page.

I'm not sure what, if anything, to do about these results. Perhaps nothing. If a remote supports native DSMs then, as I understand it, it will set that low nibble to $F for ordinary macros and the DSM=Internal:0 entry enables you to handle the native DSMs that have other values than $F. We don't even know if there are remotes with native device-specific multimacros, so that issue is perhaps not worth bothering with, yet. But I think it would be easy to make such multimacros read correctly into the SP page when both (a) the DSM=Internal:0 entry is present, and (b) the key is a multimacro key listed in the RDF. Any views on this?
_________________
Graham

[mathdon]

On second thoughts I realise that the bahaviour of IR.exe for device-specific multimacros is not really right. If you add a DSM for TV to the multimacro key, after two for DVD, you would get 2nd bytes of $93, $A3, $B1. The count should presumably be separate for each device, so you really want the last to be $91. Again, is it worth bothering with at present?

BTW It takes just one line of code to make them read correctly into the Special Protocols page.
_____________
Graham

[WagonMaster]

FavKey cycles thru all the FavKey entries until a key is pressed on the remote to stop the cycling. It is similar to a multimacro except that you press a button to stop whereas in a multimacro, you press a button to do the next entry.

Thanks, Binky. Part of my confusion stemmed from the fact that, on the RS 15-135, the key physically marked "HD" is called "HD[Fav]" in the RDF, but it's not a "Fav/Scan" key -- it's a multi-macro key! And it's even (very confusingly) labelled as '"fav/scan"' in the "[Buttons]" section!

The URC-8820/URC-10820 does have a "FAV" key and it really works as a "Fav/Scan" key (i.e. scrolling until you press a key to stop it, programmed with the 996 code). It too is (properly, IMHO) labelled as '"fav/scan"' in the "[Buttons]" section, which, when you consider that the RS 15-135's multi-macro key is (improperly, IMHO) labelled identically, is rather confusing!

Now, I guess one (not me, though) could argue that "Fav" could mean multi-macro and "Scan" could mean a key programmed with the 996 code, but then the URC-8820/10820 manual uses "Favorite" and "Scan" in the same breath, as if they were the same thing.

Oh, and the URC-8820/10820 don't even have a multi-macro key (or if they do, the RDF is missing that part!).

And I just noticed recently that in 'IR.exe', the "Scan/Fav" tab does not even appear unless (apparently) the RDF file says that the remote supports it. That's not a problem, of course, but it did partially contribute to my confusion.

So even though it's cleared up for me, the terminology and discrepancies might continue to make this a bit confusing to newcomers.

Personally, I think the "[Fav]" and "fav/scan" labels should be removed from the RS 15-135 RDF file, since the remote doesn't have a true 'Fav/Scan' (code 996) capability and since even the printed manual does not refer to "favorite" (or "scan") anywhere that I saw. (The section about that multi-macro key is titled "Programming HD Macro".)

Graham: I need to digest all that. I'll do so and reply as soon as I can. I know almost nothing about Device-Specific Macros (DSMs). Hopefully others will jump in too.

Bill

[mr_d_p_gumby]

Internal special protocols are a new concept in RDF Spec 4. They are implemented as 'macros', in the same way that 'normal' special protocols are implemented as keymoves.

...and if we're assinging blame here, this one is all yours!

A little historical perspective might help here. MultiMacros are my fault. My first JP1 remote was an old 6805-based Navigator that had three multi-macro buttons. Back then, IR did not support them, so every time I downloaded from the remote, IR would mask out what it thought were extraneous bits in the macro headers, and it really got confused when it found more than one macro assigned to the same key. Apparently, this was the philosophy Mark (Pauker) built into IR from the beginning, i.e., to "clean up" unused bits. When I conveyed details of the operation of the multi-macro keys to him, MultiMacros were his solution. Shortly after we had it working, other remotes began to surface that also had multi-macro capability, but changed the way the control bytes were structured. Mark added support for these in subsequent IR versions. These all supported a maximum of 3 macros per key. The introduction of 5 macros/key is a recent thing, and I think it is limited to the flash-based remotes. Why 3? Why 5? You'd need to ask UEI about those choices.

In all the EEPROM-based remotes, the mulit-macro control byte(s) are loaded into registers/RAM along with other setup data, such as VPT, channel lock, etc. In some of the remotes, you could see the lower nybble in the EEPROM change after each use of the key, while in others, it never changed. It really doesn't make to much difference to the user, since it will still cycle through the macros regardless of the starting value. I can see why it might not change in the flash based remotes, as it would mean a flash write every time the key was pressed, which might make the remote respond sluggishly (and unnecessarily reduce the life of the flash memory).

The Fav key support was in IR from the start, since the RS 15-1994 had such a Fav key, and was the remote that started JP1. It differs from MultiMacros in that it has it's own storage area, and it fires repeatedly at predefined time intervals until any other key is pressed.

Thanks, Binky. Part of my confusion stemmed from the fact that, on the RS 15-135, the key physically marked "HD" is called "HD[Fav]" in the RDF, but it's not a "Fav/Scan" key -- it's a multi-macro key! And it's even (very confusingly) labelled as '"fav/scan"' in the "[Buttons]" section!

The 'fav/scan" label is not a label at all. It is a "standard name" that is used to help match like keys when RM changes remotes, and to help RM understand KM files. The choice of "fav/scan" may be unfortunate in this case, but it was defined way-back-when by the keys on the 15-1994. You should not infer any special meaning to the standard names. They are simply intended as a linkage betwenn like keys on different remotes.

[gfb107]

Are internal special protocols a stock feature of these remotes, or are they something that you've added through an extender or something like that?

[mathdon]

Internal special protocols are a new concept in RDF Spec 4. They are implemented as 'macros', in the same way that 'normal' special protocols are implemented as keymoves.

...and if we're assinging blame here, this one is all yours!

Guilty as charged - though it seems that unknown to me, UEI had invented the same thing for native DSMs. Special Protocols is the only IR.exe tab into which UEI's native DSMs fit.

Are internal special protocols a stock feature of these remotes, or are they something that you've added through an extender of something like that?

I invented an internal DSM for my URC-7780/81 extenders, apparently but unknowingly identical to the UEI native one in some remotes. It then occurred to me that any Special Protocol could be implemented in the same way without the need for device and protocol assignments, so I generalised the concept for RDF Spec 4. But I've not implemented anything other than the URC-7780/81 internal DSMs. So I think the answer is a bit of both - for DSM they appear to be a stock feature in some (newer? do we know which ones?) remotes, but the general concept is intended for extenders.
_______________
Graham

[WagonMaster]

Thanks for all the clarifications and especially for the history, Mike -- very helpful! One little discrepancy/nit:

The Fav key support was in IR from the start, since the RS 15-1994 had such a Fav key, and was the remote that started JP1. It differs from MultiMacros in that it has it's own storage area, and it fires repeatedly at predefined time intervals until any other key is pressed.

(Empasis mine.) Actually, I don't believe that the emboldened part is true, at least not on my URC-8820/10820. Maybe the old JP1 (EEPROM) remotes handled it differently, though. In my case, the Fav/Scan key definition is in the same "Advanced Code" area as any other macro or keymove def. It's just marked as "Fav/Scan" (BTW, I'm assuming 'Type 1' macros here) with a special bit in the 2nd byte of a macro sequence.

Actually, as far as 'IR.exe' is concerned, I don't even know why "Scan/Fav" (as it's called on the 'IR.exe' tab) needs to have its own tab/page. (I had written more on this here, but I'm suddenly realizing that this belongs in a new thread, so as not to distract from the topic of this thread.)

The 'fav/scan" label is not a label at all. It is a "standard name" that is used to help match like keys when RM changes remotes, and to help RM understand KM files.

Ah, good. I understand better now, thanks. Unfortunate, as you say, but I can deal with it, knowing the history now. I guess I need to do even more reading of the RDF v4 spec sometime.

Bill

[mdavej]

Part of my confusion stemmed from the fact that, on the RS 15-135, the key physically marked "HD" is called "HD[Fav]" in the RDF, but it's not a "Fav/Scan" key -- it's a multi-macro key! And it's even (very confusingly) labelled as '"fav/scan"' in the "[Buttons]" section!

The URC-8820/URC-10820 does have a "FAV" key and it really works as a "Fav/Scan" key (i.e. scrolling until you press a key to stop it, programmed with the 996 code). It too is (properly, IMHO) labelled as '"fav/scan"' in the "[Buttons]" section, which, when you consider that the RS 15-135's multi-macro key is (improperly, IMHO) labelled identically, is rather confusing!

Personally, I think the "[Fav]" and "fav/scan" labels should be removed from the RS 15-135 RDF file, since the remote doesn't have a true 'Fav/Scan' (code 996) capability and since even the printed manual does not refer to "favorite" (or "scan") anywhere that I saw. (The section about that multi-macro key is titled "Programming HD Macro".)

I put "Fav" there because the manual does say something like "program up to 5 of your most viewed channels" on the HD button, which meets my definition of favorites. I didn't put "Scan" because I know it doesn't scan like a fav/scan button. So it is intended to function like a favorte channel list, albeit not scanning. It's actually the "HD" part I have trouble with. That gives me no clue at all that this is a multi-macro key.

The "fav/scan" in the Button section maps it to a fav type key in RM. Otherwise, as "HD" it wouldn't map to anything when converting upgrades from other remote models. So I chose the lesser of two evils.

Besides, UEI calls it "Fav" on it's cousin the 15-134. The 134 manual wording even uses "favorite" instead of "most viewed".

All that being said, you can change your RDF to anything you want, if that makes life easier. I do it all the time. I especially don't like RDF's that have the button names in all caps. So I change my copies of those so my macros are more readable.

[gfb107]

Special Protocols is the only IR.exe tab into which UEI's native DSMs fit.

I disagree. For remotes that support native DSMs, I would add a column to the macro tab for the device mode (which would allow a value of All in addition to the device mode/button names). For those remotes, I would also add a combo box to the macro dialog to select the device mode/button (also allowing a value of All).

I invented an internal DSM for my URC-7780/81 extenders, apparently but unknowingly identical to the UEI native one in some remotes. It then occurred to me that any Special Protocol could be implemented in the same way without the need for device and protocol assignments, so I generalised the concept for RDF Spec 4. But I've not implemented anything other than the URC-7780/81 internal DSMs. So I think the answer is a bit of both - for DSM they appear to be a stock feature in some (newer? do we know which ones?) remotes, but the general concept is intended for extenders.
_______________
Graham

I wish I had understood that when you proposed the changes for RDF 4.

There was already an example of an "internal/native" special protocol before the URC-7780/81 extender: The 6131/Atlas PVR extender, which implements "internal/native" DSM as a keymove without the need to install a device or protocol. It uses a hard-coded setup code (TV/1103).
Unfortunately we never enhanced the RDF syntax to indicate built in setup codes, so unless dummy device and protocol upgrades were installed neither IR nor RMIR would recognize that DSM keymoves were supported, but they aren't required for operation in the remote.

Your RDF 4 spec covers this by

1. Enhancing the [SpecialProtocol] section to support specialProtocolName=deviceName/setupCode:PID
2. Addition of the [SetupCodes] section allowing addition of an entry for TV/1103

in combination with the existing [Protocols] section.

If I had understood this was not truly native to the 7780/7781, I would have pushed hard for you to follow the existing DSM special protocols model (with the changes allowing their use without having to install dummy upgrades to enable IR/RMIR support for them) as keymoves instead of reinventing the wheel.

[WagonMaster]

I put "Fav" there because the manual does say something like "program up to 5 of your most view channels" on the HD button, which meets my definition of favorites.

Yes, I see your point and I certainly don't disagree with your logic. Thanks for your input on this -- it helps my understanding even more.

I just wish the manufacturer hadn't chosen such a dumb name ("HD") for a multi-macro key!

Maybe 'IR.exe' and RMIR could somehow (i.e. based on the "[MultiMacros]" section in the RDF) highlight a key as being "multi-macro" whenever the key name is displayed? I'm not really pushing for such a change now, but it bears entertaining, I think.

All that being said, you can change your RDF to anything you want, if that makes life easier. I do it all the time.

I didn't really ever want to start tweaking my own RDFs, but I too have been annoyed by all-uppercase names, so maybe I'll start.

By the way, IIRC, the RS 15-135 RDF isn't in the big file of distributed RDFs. How do they get aggregated? Could it be added to the "master" RDF file?

Bill