Beta testers needed for RCA RCRP05B extender

[ElizabethD]

...In fact I don't think there is a single Dev_Cancel in my setup

Yikes! You're right. The facts just defeated me. I edited my earlier post.

I know that I could just embed the contents of the Shift-DEV macro into the "long" portion of the Phantom1 LKP to streamline a little bit more. But this way, I can perform system set up with either Long-DEV or Shift-DEV

Putting shift-device macro on the long side of LKP is fine and is the fastest way to convert standard setup to extension. It'll serve your fingers well. I can't do that, because I need to control virtual devices using shift-AUD and shift-CBL and all that is working correctly. Nice, nice, very nice extender.

But Liz gave me another idea. I now have one macro that sets all dev key groups that I call first, then set just the exceptions

I can't take credit for this gem. Credit goes to David Vasques who wrote 8910 extender - this is the default macros which you then tweak for exceptions:

1 Phantom1 SET_TRANS_KEYS;SET_VOL_KEYS;SET_CHAN_KEYS;
SET_MENU_KEYS;SET_PIP_KEYS;SET_OTHER_KEYS;SET_LCD
2 VCR DEV_VCR;Phantom1
3 CBL DEV_CBL;Phantom1
4 SAT DEV_SAT;Phantom1
5 TV DEV_TV;Phantom1
6 CD DEV_CD;Phantom1
7 AUX DEV_AUX;Phantom1
8 DVD DEV_DVD;Phantom1
9 RCVR/AMP DEV_AUD;Phantom1
10 Home_Theater DEV_VCR;SET_TRANS_KEYS;DEV_AUD;SET_VOL_KEYS;
DEV_CBL;SET_CHAN_KEYS;SET_MENU_KEYS;
SET_OTHER_KEYS;DEV_TV;SET_PIP_KEYS;DEV_DB08
[MySys];SET_LCD

[ElizabethD]

I realized that, while my Shift-DEV macro was properly configuring all my hardware just like a Long-DEV press, it wasn't leaving the remote in the proper state to control the selected DEVice.

Actually, you could've left your shift_Device macro in place, and it end of it, call the device itself, like this
Shift-DVD macro:Dev_DVD; fewOtherButtons; DVD
DVD at the end will call your DVD macro which calls short or long side of the LKP job and therefore control the DVD completely.

Isn't it great that even though there are RDF issues, we're all able to run the extended remote in no time really? Good job, unclimiltie!

[jimdunn]

...In fact I don't think there is a single Dev_Cancel in my setup

Yikes! You're right. The facts just defeated me. I edited my earlier post.

Well, it could just be how I do things.

The 8910 readme says:

There is also DEV_Cancel command which will cancel the current DEV_
command in a macro. If the above example were intended for use as a
top level macro, there would be no need for it to explicitly cancel its DEV_
command. If the above example were in a general purpose macro that might
be called by other macros, you probably should change it to:
DEV_TV; 0; 3; DEV_Cancel

But I'm not clear on whether this means DEV_Cancel reverts to whatever DEV was active before the last DEV_xxx (in a kind of Push/Pop scenario), or "just cancels", and if it "just cancels", then what is the active device for the current macro after the "cancel"?

It can, as I understand it, only apply within a (possibly nested) macro sequence, because it's temporary device selection within macros, and the SET_KEYS commands govern what happens in "userland" on the remote when the chain of macros terminates, so it's not going to affect any "mode" the user could be "left in".

Probably a misunderstanding on my part, but as a result I've always found it easier to use explicit DEV_xxx commands as necessary in each macro (after all, if the currently active DEV is TV, and I want it to be something else, DEV_xxx is as easy as Dev_Cancel, and much clearer)

If, in fact, it is using a Push/Pop, then I could be missing some economies somewhere if I understood it.

In effect, I guess I'm saying that because I'm not entirely clear what Dev_Cancel is "supposed" to do, and because, each time I thought I knew, it didn't do what I expected - I just don't use it.

But then, chances are, I'm just missing something obvious - some Dev_Cancel "moment of clarity", if you like...
__________________________________________

Sorry to unclemiltie for taking this off-topic.

Back on topic, I think I'll get myself one of these remotes - only $15 ish on Amazon, less device buttons than I'd like, but lots of possibilities with LKP and the extra "buckets", and lots of memory -
and this extender seems too cool to miss...

[unclemiltie]

But I'm not clear on whether this means DEV_Cancel reverts to whatever DEV was active before the last DEV_xxx (in a kind of Push/Pop scenario), or "just cancels", and if it "just cancels", then what is the active device for the current macro after the "cancel"?

What happens is that when you run a string of Dev_x commands, the "temporary device" (a register in the extender named R_DevX) is set to that device until is changed or cancelled. The Dev_Cancel command will set the value in R_DevX as "invalid"

When the extender is processing a key other than a Dev_xx, Set_xx or Dev_Cancel it first looks to see if the value in R_DevX is valid. If it is valid, it will use that temporary device to process the key.

If the value in R_DevX is not valid, the extender then looks up the key to see which keyset it belongs to, looks up the device index in the HT device table and then processes that key using the device that was found in the HT device table.

Finally, when the extender passes control back to the base remote it invalidates R_DevX, the net effect is that for every macro that you define and process there is an implicit Dev_Cancel on the end so you really don't have to do that as part of your macro.

[jimdunn]

But I'm not clear on whether this means DEV_Cancel reverts to whatever DEV was active before the last DEV_xxx (in a kind of Push/Pop scenario), or "just cancels", and if it "just cancels", then what is the active device for the current macro after the "cancel"?

What happens is that when you run a string of Dev_x commands, the "temporary device" (a register in the extender named R_DevX) is set to that device until is changed or cancelled. The Dev_Cancel command will set the value in R_DevX as "invalid"

When the extender is processing a key other than a Dev_xx, Set_xx or Dev_Cancel it first looks to see if the value in R_DevX is valid. If it is valid, it will use that temporary device to process the key.

If the value in R_DevX is not valid, the extender then looks up the key to see which keyset it belongs to, looks up the device index in the HT device table and then processes that key using the device that was found in the HT device table.

Finally, when the extender passes control back to the base remote it invalidates R_DevX, the net effect is that for every macro that you define and process there is an implicit Dev_Cancel on the end so you really don't have to do that as part of your macro.

Ok.
That's fantastic - and I thank you.

I guessed it would just be one "temporary device" register that was set, because push/pop would involve a stack of some sort.

Now, not only do I know that, I also know that there's an "invalid" option, which works as you outlined, causing the program flow to "look the key up" if that register is "invalid" and that finally answers for me what Dev_Cancel actually does.

In effect, after a Dev_Cancel, it seems the remote now has to "look the key up" and do what it would be set to do do "anyway" at this point, in the event the macro had now ended, even though it hasn't, and I can now easily see how that could be useful (and conversely confusing)

In my own perverse logic I'd probably call that something like Dev_Userland, Dev_Default or Dev_Lookup instead of Dev_Cancel - but I'm sure there are a thousand problems with that (and just as many better names)...

Understanding is all, and I thank you for giving me that - you are a legend.
I think this was the Dev_Cancel "moment of clarity" I sought...
Unless I still have it all wrong

Jim

[ElizabethD]

I think things are clearer a bit. Still I'm posting this to both share and ask. Partly because while I was fiddling, you guys were in this serious conversation which I still need to absorb.

Perhaps I need to partly retract my retraction about Dev_Cancel.
Perhaps I changed IR last night but didn't reload. And when I loaded it up today, it didn't work well.
So, starting from scratch in this Dev_Cancel confusion, and trying to enlighten myself ...

When I call a common LKP, I do need Dev_Cancel in my setup. I just did this simple experiment. Comments and explanations most welcome.

Given this common set-keysets macro I use in every device
Phantom9 macro = Set_Trans;Set_Chan;Set_PIP;Set_Menu;Set_Other
I made two device macros, one on button 5, the other on button 6.
The purpose of the macros is to setup a TV device.

5 macro = Dev_AUD;Set_Vol;Dev_TV;Phantom9;Dev_AUD;Phantom5
where AUD/Phantom5 =LKP(4) [Short]:Dev_Cancel;2 [Long]:Dev_Cancel;3
> short press - 2 went to TV, subsequent key presses went to TV
> long press - 3 went to TV, subsequent key presses went to TV
That's what I want it to do.

6 macro = Dev_AUD;Set_Vol;Dev_TV;Phantom9;Dev_AUD;Phantom6
where AUD/Phantom6 =LKP(4) [Short]:2 [Long]:3
> short press - 2 went to AUD, subsequent key presses went to TV
> long press - 3 went to AUD, subsequent key presses went to TV
I wanted 2 and 3 to be TV, the calling device, signals so that didn't work for what I need.

The reason for the 2 button check is to confirm that with a short press I'll control TV by subsequent key presses.

The sort of thing 3 represents here for me are keymoves on the device I'm setting up, TV in this instance. Perhaps that's what makes Dev_Cancel needed for me?

[unclemiltie]

I
5 macro = Dev_AUD;Set_Vol;Dev_TV;Phantom9;Dev_AUD;Phantom5
where AUD/Phantom5 =LKP(4) [Short]:Dev_Cancel;2 [Long]:Dev_Cancel;3
> short press - 2 went to TV, subsequent key presses went to TV
> long press - 3 went to TV, subsequent key presses went to TV
That's what I want it to do.

6 macro = Dev_AUD;Set_Vol;Dev_TV;Phantom9;Dev_AUD;Phantom6
where AUD/Phantom6 =LKP(4) [Short]:2 [Long]:3
> short press - 2 went to AUD, subsequent key presses went to TV
> long press - 3 went to AUD, subsequent key presses went to TV
I wanted 2 and 3 to be TV, the calling device, signals so that didn't work for what I need.

This is the expected behavior. Once the extender starts processing keys, it will finish all of the keys that it needs before sending control back to the core remote. So if you call a macro from another macro, all that happens is the new macro is loaded into the macro buffer and the macro pointer gets updated to start at the end of the new macro. The extender then works its way through the macro buffer until it is empty. When the macro buffer is empty, the extender then passes control back to the core remote and on the way back invalidates R_DevX. (i.e. does the equivalent of Dev_Cancel)

Thus, you need a Dev_Cancel when you are still processing your keys. Your macros on the Phantoms, the number keys and the LKP are all processed from within the extender so there would be no implicit dev_cancel from within.

[Capn Trips]

I
5 macro = Dev_AUD;Set_Vol;Dev_TV;Phantom9;Dev_AUD;Phantom5
where AUD/Phantom5 =LKP(4) [Short]:Dev_Cancel;2 [Long]:Dev_Cancel;3
> short press - 2 went to TV, subsequent key presses went to TV
> long press - 3 went to TV, subsequent key presses went to TV
That's what I want it to do.

6 macro = Dev_AUD;Set_Vol;Dev_TV;Phantom9;Dev_AUD;Phantom6
where AUD/Phantom6 =LKP(4) [Short]:2 [Long]:3
> short press - 2 went to AUD, subsequent key presses went to TV
> long press - 3 went to AUD, subsequent key presses went to TV
I wanted 2 and 3 to be TV, the calling device, signals so that didn't work for what I need.

This is the expected behavior. Once the extender starts processing keys, it will finish all of the keys that it needs before sending control back to the core remote. So if you call a macro from another macro, all that happens is the new macro is loaded into the macro buffer and the macro pointer gets updated to start at the end of the new macro. The extender then works its way through the macro buffer until it is empty. When the macro buffer is empty, the extender then passes control back to the core remote and on the way back invalidates R_DevX. (i.e. does the equivalent of Dev_Cancel)

Thus, you need a Dev_Cancel when you are still processing your keys. Your macros on the Phantoms, the number keys and the LKP are all processed from within the extender so there would be no implicit dev_cancel from within.

Or if you absolutely want your "2" and "3" commands to be executed by the TV, then you could put "DEV_TV" before them and leave no ambiguity.

[ElizabethD]

Capn Trips, I can't. Because this is a common LKP job for all devices. Whatever device I press this, and only this, one runs
AUD/Phantom8 = LKP(4) [Short]:Dev_Cancel [Long]:Dev_Cancel;SHIFT-Day+;SHIFT-Day+;SHIFT-Day-
It is called at the end of every device button.
Those shift-Day things are keymoves, Day+ for tv inputs, Day- for receiver inputs. They must go to the device I pressed, not to AUD.

Mind you, of course I could have 5-6-7-8 such LKP jobs, one for each device in which case what you say is totally correct.
And even though Bill answered, I'm still not 100% sure the kemoves cause the need for cancel since it's so unpopular Just tweaking and trying to learn here on this new, nice, extender.

I'm so happy to see you here, 'cause you're the extender expert and often explain things in words I can understand

[R2-M0]

AUD/Phantom8 = LKP(4) [Short]:Dev_Cancel [Long]:Dev_Cancel;SHIFT-Day+;SHIFT-Day+;SHIFT-Day-
It is called at the end of every device button.

And even though Bill answered, I'm still not 100% sure the kemoves cause the need for cancel since it's so unpopular Just tweaking and trying to learn here on this new, nice, extender.

If I understand this all correctly, then the Dev_Cancel on [Short] is unnecessary, but the Dev_Cancel on [Long] is required.

From what you've said, the last commands in each Device macro would be "Dev_AUD,Phantom8". Without the Dev_Cancel in the [Long] portion, the SHIFT-Day+ and SHIFT-Day- commands would be run from the AUD mappings (since Dev_AUD would still be active).

The Dev_Cancel clears out the temporary device register, however. So SHIFT-Day+ and SHIFT-Day- will instead be run from whatever device was last associated to the Menu button group. And that's the behavior you're looking for here.

[Capn Trips]

Well, I do not have this remote, so have not looked at the extender at all, but my theory is "if it works, don't fix it" and you say that what you have works, so what's the problem?

But just so that I understand, you have assigned keymoves to "DEV"/shift-Day+ that send INPUT "DEV" to the TV and similarly to
"DEV"/shift-Day- that send INPUT "DEV" to your amplifier/receiver, correct?

Then Dev_Cancel on the LKP side is what you need, since by that time you will have assigned the "Channel", "Menu" and "Other" keysets to the desired "DEV" (and I assume that Day+/- belongs to one of those keysets).

I would point out that on the SKP side, however, you are simply wasting a byte with the DEV_Cancel, since that's the last step in your sequence anyways (AFAICT). (At least I've never successfully had ANOTHER button execute after an LKP sequence.)

[ElizabethD]

From what you've said, the last commands in each Device macro would be "Dev_AUD,Phantom8".

Correct.

Without the Dev_Cancel in the [Long] portion, the SHIFT-Day+ and SHIFT-Day- commands would be run from the AUD mappings (since Dev_AUD would still be active).

And that's exactly what test on macro5 showed above.

But just so that I understand, you have assigned keymoves to "DEV"/shift-Day+ that send INPUT "DEV" to the TV and similarly to "DEV"/shift-Day- that send INPUT "DEV" to your amplifier/receiver, correct?

Yes. TV/Shift-day+, DVD/shift-day+, dev4/shift-day+ etc, are keymoves for inputs to TV. And all shift-Day- are to AUD.

Problem? Well, it all started with us talking variations of design. And the Dev_Cancel can of worms got opened. So I decided to start thinking from scratch.

Happy news: We're all on the same page now. And I understand it better.
Oh, I will drop cancel on the short side. No issue here.

[jimdunn]

Funny thing is, I've been implicitly using this behaviour already in macros that don't set a device with Dev_xxx - such as using Shift-Vol/Shift-Mute in macros to send the different native device volume/mute commands to whatever device is active (Vol/mute keys themselves are always mapped to receiver).

The only thing I needed to realise in order to actually understand Dev_Cancel was that issuing Dev_Cancel just gets me back to the state as though no Dev_xxx commands had been issued in the macro.

It's embarrassingly simple, once I "get" that.

[unclemiltie]

Just for clarity (although it's not in this extender)

The "other style" HT keysets that are in the other extenders (like the Atlas, et al) function in a similar way.

When you do an X_VCR, you are setting the temporary device (R_DevX) to be the VCR. The X_Cancel will invalidate R_DevX.

The logic of how the extender processes a key is exactly the same: if R_DevX is valid, it will be used, if not, the key is validated against the keylists and the appropriate device is loaded and processed.

The difference in the "styles" is in the commands to set an entry in the device table.

The "Atlas" style uses a single command to set each device. i.e. to load the VCR as the device for the transport keys you would use T_VCR.

The "8910" style uses multiple commands to set the device. i.e. to load the VCR as the device for the transport keys, you would use Dev_VCR, Set_Trans.

The benefits of the "atlas" style is that it allows for small numbers of keys to be used in macros, etc to load up the device table. The downside is that you need to define a lot of keys (the number of devices TIMES the number of keysets) some of the remotes don't have room for those.

The benefits of the "8910" style is that it uses a lot fewer keys (number of devices PLUS the number of keysets) The downside is that the macros to set up the HT device table can be a lot longer, but can also be shortened if a lot of things are "common."

[unclemiltie]

Now, back to our regularly scheduled program:


How's all of the testing going? It appears that we have 4 or 5 people using the extender to some success. Am I at a point where with the RDF updates that have been discussed here that I could release this thing wider?

I've built and updated V0.3 that has all of the changes that we have discussed so far. I think that I'd like to have a wider beta for a couple of weeks and then general release. Sound like a plan?