protocols.ini question

[The Robman]

If and when I get the time, I'd like to go through protocols.ini and clean things up, adding entries for protocols that are not yet supported and simplifying support for protocols that have many variants. To do this I need to make sure that I understand how things work when there are multiple variants as this isn't explained in the comments at the top.

When there are multiple variants of a single protocol, as is the case with "Pioneer MIX" for example, I assume that RM will check which version is pre-installed in your remote once you have selected a remote and it will use the appropiate variaint from the protocols.ini list. What happens when the protocol is missing completely from the remote, does it default to the version with the highest VariantName number?

I assume that the only way to give the user the ability to select a specific version of a protocol is to create a seperate entry using a different protocol name. If this is the case, would it be possible for RM to support the concept of "Alias" entries, which would eliminate the need to copy all of the entry data from one of the current entries. If we go with this option, I'd like to be able to state in the entry which versions are acceptable and which version is the "preferred" version (ie, the one that will be supplied when the remote doesn't have any of the acceptable versions installed).

[gfb107]

When there are multiple variants of a single protocol, as is the case with "Pioneer MIX" for example, I assume that RM will check which version is pre-installed in your remote once you have selected a remote and it will use the appropiate variaint from the protocols.ini list. What happens when the protocol is missing completely from the remote, does it default to the version with the highest VariantName number?

No, it defaults to the first one listed in protocols.ini

I assume that the only way to give the user the ability to select a specific version of a protocol is to create a seperate entry using a different protocol name.

Correct.

If this is the case, would it be possible for RM to support the concept of "Alias" entries, which would eliminate the need to copy all of the entry data from one of the current entries.

I'll consider it. As an alternative, we could expose the variant name to the user (maybe this could be enabled through the Options or Advanced menu s). When the user selects a protocol, RM would automatically select the variant built into the remote (if there is one), or the first one listed in protocols.ini (if there isn't one built into the remote).

If we go with this option, I'd like to be able to state in the entry which versions are acceptable and which version is the "preferred" version (ie, the one that will be supplied when the remote doesn't have any of the acceptable versions installed).

I'm not clear on what you're asking for here.

[The Robman]

I'm not clear on what you're asking for here.

A good exec to use an example for this is the $007E Pioneer exec. It started life as a simple DVD exec, which we called "Pioneer DVD", then they expanded it so that it covered a wider range of Pioneer products. This next version was called "Pioneer MIX". Then they expanded it again so that you could combine up to 4 different command codes in it, this version is called "Pioneer MIX 4-cmd". Typically, as UEI expands the capabilities of an exec, they also make it larger. When a user needs needs a protocol upgrade, they don't necessarily need the most up to date version of the exec, it all depends on what they're trying to do. If a user selects the "Pioneer MIX" protocol, for example, variant 2 and variant 3 are both acceptable versions, but if the user doesn't have any version of this exec, I might want to give them the smaller #2 version rather than the #3 version.

If the "Pioneer MIX" protocols.ini entry were an "Alias" entry, I might want to state that variants 2 thru 5 are acceptable, but that version 2 was preferred. The syntax might be somthing like...

Variants:2,{3,4,5}

[johnsfine]

No, it defaults to the first one listed in protocols.ini

My understanding and hope is that it defaults to the first one that has an executor provided in the protocols.ini for the right CPU.

So by leaving out a given CPU's executor from a given protocols.ini entry you can safely place that entry earlier within protocols.ini (for some desired effect in case the remote has a different CPU and/or has that varient built in). But that entry will not affect the choice of entry for remotes that can't use it at all.

[johnsfine]

then they expanded it so that it covered a wider range of Pioneer products. This next version was called "Pioneer MIX". Then they expanded it again so that you could combine up to 4 different command codes in it, this version is called "Pioneer MIX 4-cmd". Typically, as UEI expands the capabilities of an exec, they also make it larger. When a user needs needs a protocol upgrade, they don't necessarily need the most up to date version of the exec, it all depends on what they're trying to do.

I never thought of a good way to represent and manage these multi-way relationships. Greg has built RM's varient support basically following my concepts of how varients should be managed.

A "protocol name" in this view should fairly consistently (across remotes and executors) indicate what code sets you could create.

The muilt-way overlap occurs when an executor's abilities are a superset of some other executor's abilities.

The natural way to represent that in my scheme is to have:

1) A protocol name for the first executor's abilities and TWO protocol.ini entries, one to accomplish that with the bigger executor only when built-in (no code should be provided) and another to accomplishe that with the smaller executor (with code provided) used whenever the bigger one is not built-in.

2) Another protocol name for the wider set of abilities with a protocols.ini entry with code to use the bigger executor whether built-in or not.

It's a little dissatisfying to need three protocols.ini entries for the two varients. It a little confusing to have two names for basically the same thing, with one just a little more flexible than the other. But I couldn't think of a more workable system.

As you get to multiple layers of executor with increasing ability, the above affect of three entries for two executors expands geometrically, not just linearly, so it gets a lot more annoying for the protocols.ini maintainer. But I still can't think of a better way.

[gfb107]

My understanding and hope is that it defaults to the first one that has an executor provided in the protocols.ini for the right CPU.

So by leaving out a given CPU's executor from a given protocols.ini entry you can safely place that entry earlier within protocols.ini (for some desired effect in case the remote has a different CPU and/or has that varient built in). But that entry will not affect the choice of entry for remotes that can't use it at all.

Correct.

[The Robman]

As you get to multiple layers of executor with increasing ability, the above affect of three entries for two executors expands geometrically, not just linearly, so it gets a lot more annoying for the protocols.ini maintainer. But I still can't think of a better way.

If we were to go with my Alias idea, we could have one master set of entries for execs like the $007E exec, then we could use the Alias entries (which will be largely 'bare bones' entries, to determine which variants should be used for any given circumstances.

I think having multiple entries for the same variant is unavoidable (when the variant is capable of performing different tasks) but I don't like the idea of having to duplicate the guts of each entry, especially when it comes to maintaining them in the future.

[gfb107]

A pure alias, where only the name (and variant name) changes would be pretty simple to do.

If, on the other hand, you want one or more of the device parameters to have different names or default values or even add/remove some, that's a different story.

[The Robman]

A pure alias would certainly be a start and might in fact cover all of our needs, but as a future option it would be cool to be able to override one or two of the original entries.