JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Adding DSM support to IR
Goto page 1, 2  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

                    
PostPosted: Thu Feb 05, 2004 2:20 pm    Post subject: Reply with quote

e34m5 wrote:

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).
Back to top
View user's profile Send private message Send e-mail Visit poster's website
e34m5



Joined: 14 Oct 2003
Posts: 675
Location: Atlanta

                    
PostPosted: Thu Feb 05, 2004 2:33 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

                    
PostPosted: Thu Feb 05, 2004 3:21 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
e34m5



Joined: 14 Oct 2003
Posts: 675
Location: Atlanta

                    
PostPosted: Thu Feb 05, 2004 3:35 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Nils_Ekberg
Expert


Joined: 02 Aug 2003
Posts: 1689
Location: Near Albany, NY

                    
PostPosted: Thu Feb 05, 2004 3:42 pm    Post subject: Reply with quote

e34m5 wrote:

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.

e34m5 wrote:
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 Exclamation
_________________
Nils
Files Section
Diagnosis File Section
Back to top
View user's profile Send private message Send e-mail
e34m5



Joined: 14 Oct 2003
Posts: 675
Location: Atlanta

                    
PostPosted: Thu Feb 05, 2004 3:50 pm    Post subject: Reply with quote

Nils

I was beginning to formulate the same idea as your number 2.
Back to top
View user's profile Send private message
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

                    
PostPosted: Thu Feb 05, 2004 3:53 pm    Post subject: Reply with quote

Nils_Ekberg wrote:

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 Exclamation


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).
Back to top
View user's profile Send private message Send e-mail Visit poster's website
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

                    
PostPosted: Thu Feb 05, 2004 4:10 pm    Post subject: Reply with quote

e34m5 wrote:

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.)
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Nils_Ekberg
Expert


Joined: 02 Aug 2003
Posts: 1689
Location: Near Albany, NY

                    
PostPosted: Thu Feb 05, 2004 4:17 pm    Post subject: Reply with quote

johnsfine wrote:
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.
_________________
Nils
Files Section
Diagnosis File Section
Back to top
View user's profile Send private message Send e-mail
e34m5



Joined: 14 Oct 2003
Posts: 675
Location: Atlanta

                    
PostPosted: Thu Feb 05, 2004 7:56 pm    Post subject: Reply with quote

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".
Back to top
View user's profile Send private message
Nils_Ekberg
Expert


Joined: 02 Aug 2003
Posts: 1689
Location: Near Albany, NY

                    
PostPosted: Thu Feb 05, 2004 8:31 pm    Post subject: Reply with quote

e34m5 wrote:
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... Exclamation
_________________
Nils
Files Section
Diagnosis File Section
Back to top
View user's profile Send private message Send e-mail
e34m5



Joined: 14 Oct 2003
Posts: 675
Location: Atlanta

                    
PostPosted: Mon Feb 09, 2004 1:56 pm    Post subject: Reply with quote

Is the protocol ID for DSM always 1FC regardless of which remote the extender is for??
Back to top
View user's profile Send private message
Nils_Ekberg
Expert


Joined: 02 Aug 2003
Posts: 1689
Location: Near Albany, NY

                    
PostPosted: Mon Feb 09, 2004 2:26 pm    Post subject: Reply with quote

e34m5 wrote:
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.
_________________
Nils
Files Section
Diagnosis File Section
Back to top
View user's profile Send private message Send e-mail
e34m5



Joined: 14 Oct 2003
Posts: 675
Location: Atlanta

                    
PostPosted: Tue Feb 10, 2004 3:44 pm    Post subject: Reply with quote

Man there is some nasty code in IR Very Happy . 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
Back to top
View user's profile Send private message
mpauker
Expert


Joined: 03 Aug 2003
Posts: 40

                    
PostPosted: Mon Feb 16, 2004 8:24 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control