JP1 Remotes

[ElizabethD]

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

[Nils_Ekberg]

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

[unclemiltie]

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.

[johnsfine]

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.

[e.axel]

How about just pushing the button twice???

[floyd1977]

[ElizabethD]

[johnsfine]

[floyd1977]

[ElizabethD]

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

[vickyg2003]

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.

[Nils_Ekberg]

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

[ElizabethD]

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

[Nils_Ekberg]

[ElizabethD]

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.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride