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

Need a way to repeat a macro
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2310

PostPosted: Mon Mar 05, 2007 4:41 pm    Post subject: Need a way to repeat a macro Reply with quote

Is there a way to repeat last macro, not just a last command, while the key is down?
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
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 Mar 05, 2007 4:46 pm    Post subject: Reply with quote

No manual way that I am aware of.

My guess is a special protocol might work but it could be pretty complex.
_________________
Nils
Files Section
Diagnosis File Section
Back to top
View user's profile Send private message Send e-mail
unclemiltie
Expert


Joined: 21 Jan 2004
Posts: 1790
Location: Pittsburgh, PA

PostPosted: Mon Mar 05, 2007 8:57 pm    Post subject: Reply with quote

yea, it would be complex. The special protocol would have to deal with the protocol getting unloaded for every key in the macro and then have to start over again.

Better would be doing an extender that checked for the same keypress after the macro finished playing. The good news is that the data is still in the macro buffer so you wouldn't have to search/find/re-read. the bad news is that the newer extenders have the key-reading part in part_1 and the macro loading and key processing stuff in part_2 so it'd be a complex back-and-forth.
Back to top
View user's profile Send private message
johnsfine
Site Admin


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

PostPosted: Mon Mar 05, 2007 9:39 pm    Post subject: Reply with quote

I think the best way is:

1) Write a special protocol similar in construction to an extender ToadTog in having two branches one of which is executed. But instead of deciding which branch to execute the way ToadTog does, it would decide based on whether the original key is still down (something fairly easy for a special protocol to check).

2) End the macro with a keymove of that special protocol, in which the still pressed branch issues the macro again (by its single keycode, because macros can nest) and the not pressed branch does nothing.

Obviously there are lots of slightly simpler special protocol designs that could serve the same purpose in this example, but this design covers all the cases of wanting control based on whether the originating key is still pressed.

Note that the special protocol does not have any reason to stay in control the whole time. Its job is done once at the end of each iteration of the macro with no need or even reason to retain more context.

Similarly, this is actually simpler for a special protocol than it would be for extra code within the extender body. And of course it would be much easier to deliver as a special protocol.

A special protocol could also do the slightly simpler job of rewinding the macro buffer. But that would be confusing if the macro had nested other macros, and anyway it is less general purpose than just reissuing the macros keycode.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
e.axel
Exile Island Resident


Joined: 03 Feb 2006
Posts: 209

PostPosted: Mon Mar 05, 2007 10:05 pm    Post subject: Reply with quote

How about just pushing the button twice???
Back to top
View user's profile Send private message
floyd1977



Joined: 10 May 2006
Posts: 198
Location: Montgomery, IL

PostPosted: Tue Mar 06, 2007 8:31 am    Post subject: Reply with quote

e.axel wrote:
How about just pushing the button twice???


My guess is that Liz wants the macro to execute several times. The only good example I can think of for this is two independent volume controls.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2310

PostPosted: Fri Mar 09, 2007 5:31 pm    Post subject: Reply with quote

unclemiltie wrote:
extender that checked for the same keypress after the macro finished playing
That's one scenario. An option worth handling at the same time is to give it a fixed count. If the count is zero, control repeats by holding, otherwise use the counter but where?

johnsfine wrote:
Note that the special protocol does not have any reason to stay in control the whole time. Its job is done once at the end of each iteration of the macro with no need or even reason to retain more context.

Thanks, John. That's very nice design. Can you elaborate on the quote? I have to think about it and maybe try some code. So you would not make a special protocol keymove calling that macro over and over? 'Cause that was one of the ways I was thinking as I started to think about it for a bout 5 minutes.

e.axel wrote:
How about just pushing the button twice???

Well, that's one too many Smile is it not? And I need it for >2, perhaps as much as 10-12 times. Heck, 32 or forever, if extender permits.

floyd1977 wrote:
two independent volume controls

Do you mean code it on volume buttons? I can try. I doubt it'll work, 'cause volume is punched through to the tuner.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
johnsfine
Site Admin


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

PostPosted: Fri Mar 09, 2007 6:00 pm    Post subject: Reply with quote

ElizabethD wrote:
Can you elaborate on the quote?


Not sure what else you want to know, and I'm not sure I even could elaborate without research (review how toadtog works in the relevent extender and review how to check whether the original key is still down). I know all the details are available, but they aren't in my head.

ElizabethD wrote:
So you would not make a special protocol keymove calling that macro over and over?


Depends what you mean by that. But I think you mean staying in control, which is unnecessary and harder than what I described.

1) The main macro is bound directly to the desired key.

2) The macro starts by doing all the commands that you want done for one iteration of the loop.

3) The macro ends by issuing the phantom key on which the special keymove is bound.

4) The special keymove contains the keycode of the macro, and if you make the general version I suggested also contains a flag byte to say how much it contains in each of its two branches (1 keycode in one branch and 0 keycodes in the other for this simple use).

5) The special protocol checks whether the (original physical) key is still down and if so it issues the appropriate branch, which in this case is the single key code to start the whole thing over.

At the end of every pass through the macro, you will re invoke the special protocol. So it has no need to remain in control.

This may look like unlimited nesting, that would overflow some stack, if we used a normal stack to nest macros. But the extenders nest macros in a way that is immune to that problem as long as the special keymove is invoked as the very last step of the macro.

It may be counterintuitve that the special protocol can check whether the original physical key is still pressed, without needing to know what that key is and long after the macro has issued many other keycodes. But in fact, the firmware remembers the original physical key, and includes an entry point to check whether it is still pressed and extenders already use that feature in order to extend the last keycode of a macro. That may also depend on the special keymove being last in the macro.

If I remember correctly, many ordinary protocols call the check to see if the original key is still pressed. The extender intentionally breaks that feature during execution of a macro for all steps in the macro except the last, then repairs that feature while executing the last step.

So the special protocol can check for key still pressed the same simple way that ordinary protocols do.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
floyd1977



Joined: 10 May 2006
Posts: 198
Location: Montgomery, IL

PostPosted: Fri Mar 09, 2007 7:57 pm    Post subject: Reply with quote

ElizabethD wrote:
floyd1977 wrote:
two independent volume controls

Do you mean code it on volume buttons? I can try. I doubt it'll work, 'cause volume is punched through to the tuner.
[/quote]

No, no. Someone suggested just pushing the button twice if you want to repeat a macro, but I was just trying to think of an example of why someone might want to repeat a macro when you hold down a button. One scenario I thought of is if you had two receivers and wanted vol+ to be a macro that sent vol+ to receiver 1 and receiver 2 repeatedly.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2310

PostPosted: Wed Mar 14, 2007 11:11 am    Post subject: Reply with quote

John,
On 6131, it works very well with the keymove at the end of the macro. Thank you!
Now, I did not configure it similar to ToadTog's two sides. The key reason is that I don't understand what it would do for me, or how that would make it more general than simply watching the button and putting it on the stack (or do nothing on release). But I bet you're onto something I haven't imagined, so I'd like to hear more about
johnsfine wrote:
4) The special keymove contains the keycode of the macro
it does, just one byte
johnsfine wrote:
, and if you make the general version I suggested also contains a flag byte to say how much it contains in each of its two branches (1 keycode in one branch and 0 keycodes in the other for this simple use).
since I don't store a flag or data anywhere, I don't see how the keymove with two sides would fit and if there's just one side, I don't have to fiddle with adjusting the position.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7055
Location: Florida

PostPosted: Wed Mar 14, 2007 11:39 am    Post subject: Reply with quote

Hmm,

Okay, I'm going to reveal my ignorance here, but couldn't you write a protocol that would insert itself if the key is still being held down, before it unpacks its macro contents? Recurrsion if you will?
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Back to top
View user's profile Send private message Visit poster's website
Nils_Ekberg
Expert


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

PostPosted: Wed Mar 14, 2007 11:55 am    Post subject: Reply with quote

If you knew the amount of times you want the macro to run you could just put it that number of times on for example the long side of LKP. Of course you are limited to how many entries you can put on the long side but it would work (I just watched my TV change modes to DVR (2 steps for DVR and 4 for TV modes) 11 times on the long side and one on the short side. In other words it executed 8 steps in a macro 11 times.

I suspect what you are really looking for is a protocol the held 1 parm for the macro button and one for how many repeats.
_________________
Nils
Files Section
Diagnosis File Section
Back to top
View user's profile Send private message Send e-mail
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2310

PostPosted: Wed Mar 14, 2007 12:31 pm    Post subject: Reply with quote

Nils, I did earlier ask about an alternative of macro vs fixed number of repeats, but then decided I don't need it because one can make a composite sequence as you did. Perhaps that's what John was answering, but he might have bigger ideas.

Currently, repeats stop as soon as you change the key state, and the extender goes on about its work based on r_closures I suppose. Without storing the flag and changing it how would the keymove know what triggers one side vs another?
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
Nils_Ekberg
Expert


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

PostPosted: Wed Mar 14, 2007 1:11 pm    Post subject: Reply with quote

ElizabethD wrote:
Currently, repeats stop as soon as you change the key state, and the extender goes on about its work based on r_closures I suppose. Without storing the flag and changing it how would the keymove know what triggers one side vs another?

Single OBC/EFC repeats stop as soon as you release the button (based on the executor/protocol) but if it is a macro on the button it will finish the macro. If you put 10 macros within a macro (nested like in extenders) then even if you release the button the 10 macros will continue to process. If you hold the button until the macros complete than the last EFC type command in the last macro will repeat. That assume it is a repeating executor.

This is the example I was talking about that would repeat the macro 10 times. The 1st (fake) is the LKP and the 2nd (real macro) is the DSM that it executes.

Code:

Regular Macro that starts it all:

CBL   X_CBL;DiscreteOn

LKP executed by macro:

1 CBL DiscreteOn   LKP(1)   

[Short]:XSHIFT-DiscreteOn   

[Long]:SHIFT-DiscreteOn;
       SHIFT-DiscreteOn;
       SHIFT-DiscreteOn;
       SHIFT-DiscreteOn;
       SHIFT-DiscreteOn;
       SHIFT-DiscreteOn;
       SHIFT-DiscreteOn;
       SHIFT-DiscreteOn;
       SHIFT-DiscreteOn;
       SHIFT-DiscreteOn;
       SHIFT-DiscreteOn

DSM it executes:

2   CBL   SHIFT-DiscreteOn   DSM   X_TV;SHIFT-2;SHIFT-2;SHIFT-Pause;SHIFT-3;X_Cancel   :Switch TV input

_________________
Nils
Files Section
Diagnosis File Section
Back to top
View user's profile Send private message Send e-mail
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2310

PostPosted: Wed Mar 14, 2007 1:48 pm    Post subject: Reply with quote

Nils, that is cool 11x6 for fixed number Smile When I was asking about fixed number, I didn't think to put it on LKP.
Ok, sanity check. This is my test version. I need it for [tune+,pause] repeats while holding
Macro on Advance button(29): XSHIFT-CH+;SHIFT-Angle{Sleep};XSHIFT-Phantom2
Keymove: TV XSHIFT-Phantom2 <N/A> VCR/DVD 2041 $29

To make sure we're on the same page, SP:
call ScanKeypad
JRNC Done
cp R_Mac,#AR_MacBuf
JRULE Done
LD w2,DCBUF
pushud @R_Mac,w2
Done RET

Not sure if I can drop the position check (3 bytes) against start since I don't mess with it but it hasn't crashed in two days with and without.
One thing I don't like about it - need for several triggering keymoves for different macros.
If this holds water, I'll make versions for remotes I have.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - General Forum All times are GMT - 5 Hours
Goto page 1, 2, 3  Next
Page 1 of 3

 
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
Get Smart! the band's official homepage Rockabilly Central