Adding DSM support to IR

[johnsfine]

Question: I haven't had a need for DSM so I'm not familiar but is the same protocol used for extender vs non-extender.

No. The requested IR feature barely makes sense for the non extender version.

In the extender version a DSM has a body containing multiple keycodes (like a macro). It has a slightly longer header and thus its maximum number of keycodes would be shorter (I think it's 13 for the existing extender DSMs. A macro has a max of 15).

In non extender, the DSM itself has a body containing a single keycode.

To support this, I think there should be a line in the RDF specifying the setup code to use for DSM. If the RDF lacks that field I think the feature should be disabled. It also would be nice to disable the feature if the specified setup code isn't present as an upgrade.

For non extender take your choice:

A) Don't support it. RDF's for non extender shouldn't have the line to declare DSM and IR should allow DSMs (when enabled at all) up to 13 bytes long.

B) The RDF syntax for DSM should specify maximum length as well as setup code, so non extender RDF's would specify a max DSM length of 1.

(DSM's can nest macros, so a one byte DSM is usable. But that aspect should be left to the user, not automated by IR).

[e34m5]

Since you have to use the DSM from a KeyMove the ideal would be to create the KeyMove on the fly based on the device/bound key the macro is being defined for. Using the macro create screen I need to automatically convert the keys to their hex equivalent (like CodeCalc does) and save them as the keymove.

Could we develop another Phantom type key that would be used as the place holder for this type of definition and not use up some of the current Ph1-Ph4 locations. Maybe we can declare some thing like SP1-SP4 (special prot 1-4) as the locations to hold these keymoves.

Once I figure out this methodology it can be extended (no pun) to all the special protocols that use the KeyMove paradigm (LKP,TT, etc)

Paul

[johnsfine]

We seem to have a slight failure to communicate here. Plus I had forgotten about LKP etc. and don't understand it well enough to have a good feel how it should fit in.

In non extender DSM there is a question of how much to automate. I assumed an answer to that question and I think you're assuming a different answer.

To make a non extender DSM the user now must:
1) Install the required upgrades.
2) Select a phantom and program a macro on the phnatom.
3) Select a physical key and program a DSM keymove on that physical key and translate the phantom key to a hex keycode used in that Keymove.

If you support non extender DSMs at all, I was proposing changing only step 3. It would be done on the Macros tab rather than the KeyMove Tab and IR rather than the user would translate from phantom key name to hex code.

I think you're proposing automating step 2 and 3 together. The user would define the DSM on the physical key with the body of the desired macro and IR would select a phantom key and create both the macro and the keymove. I think that's a lot more work for IR, with several pitfalls. It only saves a little effort for the user. It removes a little flexibility the user would otherwise have (having two different DSMs for the same macro).

The keycode space is getting rather ful in some cases, so blocking off a special group of phantoms for this might be a problem.

In the extender DSM there is just one object, the DSM, which the remote thinks is a KeyMove, which contains the body of the macro. No phantom is required. If the user chooses, he can put the macro on a phantom and have one or more DSMs invoke it. But that is just nesting macros. IR should not be hiding that nesting from the user, since it is done only if the user wants it.

[e34m5]

You are right..we are thinking two different things..probably because I never have done a DSM. So I need to play with that and relate it to what you are describing.

So in the DSM the way you use it is to create a macro on a key move of a specific device and then invoke from the remote by first pressing the device key and then the key that has the macro.

I think as soon as I play with the non-ex DSM it will make sense what you are requesting.

[Nils_Ekberg]

Could we develop another Phantom type key that would be used as the place holder for this type of definition and not use up some of the current Ph1-Ph4 locations. Maybe we can declare some thing like SP1-SP4 (special prot 1-4) as the locations to hold these keymoves.

I am not sure we would want to take this approach since that would force the user to put the DSM on a phantom/special key then assign it to the real key they want it on. I typically put my DSM's on the button I want them on.

Once I figure out this methodology it can be extended (no pun) to all the special protocols that use the KeyMove paradigm (LKP,TT, etc)

Agreed

They way I would envision this is two possible ways:

1) When the user creates the keymove there would be 3 options EFC, HEX, or DSM at the bottom of the keymove popup. The user would select the bound device and button, click on DSM and the SP device and number would get populated and another popup would occur just like the macro popup where the user would select the buttons (up to 13). After they click OK then the keymove would be created and look like it does today and when edited it would again look like the macro selection popup. It would be nice if the keymove actually looked like a macro.

Or

2) Move the DSM from the keymove panel to the macro panel. When ADD is selected there would be a choice on the macro popup that says Macro type: Regular or DSM. The only difference then is that the DSM is limited to 13 buttons and the regular is 15.

I vote for number 2

[e34m5]

Nils

I was beginning to formulate the same idea as your number 2.

[johnsfine]

2) Move the DSM from the keymove panel to the macro panel. When ADD is selected there would be a choice on the macro popup that says Macro type: Regular or DSM. The only difference then is that the DSM is limited to 13 buttons and the regular is 15.

I vote for number 2

I was assuming number 2 between those choices, because a good DSM GUI is much more like a Macro GUI than a KeyMove GUI. That is especially true when you think about where and how it should display the DSMs that are already defined.

But your "only difference" misses the important one. A DSM, like a KeyMove, has a bound device mode. A macro doesn't.

Earlier I suggested selecting Bound device mode on the same pull down that selects Macro vs. DSM. Having given that more thought, I realize that would paint us into a corner relative to future LKP or TT support. Better select Macro vs. DSM on one pull down and Bound Device mode on a second Pull down (that deactivates if you selet macro).

[johnsfine]

I think as soon as I play with the non-ex DSM it will make sense what you are requesting.

I think you should focus on the extender DSM first, because:

1) DSMs are more popular with extenders than without.
2) IR.EXE support will make a BIG difference in the ease of defining extender DSMs and a smaller difference in the ease of defining non extender DSMs.

After extender DSMs are done, you'll have a better understanding of how non extender DSMs should fit in, if at all.

For extender DSMs:

1) RDF entry to specify the setup code and maybe max length
2) GUI choice of Macro vs. DSM
3) GUI Bound Device pull down (similar to the KeyMove one) enabled when DSM chosen.
4) GUI change to display list of defined macro to have a bound device column when appropriate.
5) Logic to generate the longer header (including Bound device mode and setup code) for DSMs.
6) (Maybe, logic to force any real macro to be postioned after the last DSM on the same key if there are any. But I guess it's rare enough we might just leave that as a user problem.)

[Nils_Ekberg]

But your "only difference" misses the important one. A DSM, like a KeyMove, has a bound device mode. A macro doesn't.

Earlier I suggested selecting Bound device mode on the same pull down that selects Macro vs. DSM. Having given that more thought, I realize that would paint us into a corner relative to future LKP or TT support. Better select Macro vs. DSM on one pull down and Bound Device mode on a second Pull down (that deactivates if you selet macro).

Could be the same pulldown but the top half shows first with the choice of Regular vs DSM, then the lower half rolls down with the bound device and button window for a DSM and just the button window for a regular macro.

I know, no real difference just looks better to me, kiind of like the windows logon box that has detail options vs just the userid and password field. Same popup just grows with choices.

[e34m5]

Ok..I think I have a good idea of you guys want..I'll start chewing on this.

I will work on the extended version of "DSM Macro definition in IR".

[Nils_Ekberg]

Ok..I think I have a good idea of you guys want..I'll start chewing on this.

I will work on the extended version of "DSM Macro definition in IR".

Go for it... Have fun...

[e34m5]

Is the protocol ID for DSM always 1FC regardless of which remote the extender is for??

[Nils_Ekberg]

Is the protocol ID for DSM always 1FC regardless of which remote the extender is for??

It probably is because we copy alot but I could not guarantee it unless I looked at all the extenders.

I took a quick look at all the more polular extenders and they were all 1FC. Take a closer look at the 6131 though since it looks like it is actually built into the extender and not a seperate protocol.

[e34m5]

Man there is some nasty code in IR . Since I only have time to work on this a little every night it is taking quite some time to understand.

Making progress however. I am able to recognize protocols on the fly when opening the macro dialog so that IR will automatically know if DSM protocol is available.

If it is it will allow building with those prots if not it won't.

Well that's all for now

TTFN, Paul

[mpauker]

Hey Paul!

We should probably chat a bit if you're really going to take this on. If for no other reason, we should make sure that you're working on the right code base. (I'm not always that good at keeping the source files up-to-date.)

-- Mark