JP1 Remotes

Is there a way to repeat last macro, not just a last command, while the key is down?

No manual way that I am aware of.

My guess is a special protocol might work but it could be pretty complex.

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.

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.

How about just pushing the button twice???

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.

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 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.

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.

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.

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.

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?

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, 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?

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.

Nils, that is cool 11x6 for fixed number 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.