Adding 10 devices to an Atlas

[vickyg2003]

I am breaking this off from unclemilties post, just because if in the light of day or when the alcohol wears off if this seems like a really dumb idea, I can delete it.

Basking in the glow of being called "clever" I started thinking about how clever I could be, and I came up with a brilliant idea on how to find 15 keymove buckets in any remote.

Normally an extender looks up a home theater device, and then uses that device index to check for keymove, and setups.

Suppose we came up with a new multiplex protocol with an extra byte that specified a keymove bucket. Any time you multiplexed, you'd change the KM_bucket entry. So when you do your hometheater lookup to find which device index to use, you'd merely use the device index to find the device bucket. If no keymove was found, you just process the key using the normal device index.

I'm pretty sure that there isn't any device validation in the keymove proecessing but I could be wrong on this. I've done a preliminary search and can't find anyplace where the device index is used in the processing of the actual keymove, although these can be tricky and I may have missed something.

Example,

On an Atlas we have a keymove bucket table with 5 entries.

If the KM_Bucket table looked like this
KM_Bucket: 0,1,6,3,A

And your device index was 0, you'd use 0 for the keymove header search.

If the device index was 3, you'd use 6 for the keymove header search.

This really should be easy to do, and pretty understandable.

I'm just a little confused on how we'd get IR to tweak the RDF so that we could have 15 devices for the 'bound to dropdown' without breaking RemoteMaster. I'll bet that 8910 could show me how to do that.

This all hinges on how keymoves are actually processed, but it sure takes a lot of the problems out of the other approaches we've discussed. It looks like we could do this with about 20 bytes of extender code.

[xnappo]

Bartender, I'll have what she's havin'

[jimdunn]

For us lesser mortals trying to understand this:

Do you mean, this would give 15 devices in the general tab of IR
ie extra 10 devices: db06, db07, db08 etc...

You'd set up your 15 devices in IR assigned to any built in/upgrade code.

You could add keymoves to these devices in IR just like any other device.

Then when programming device selection macros you'd have commands to assign these devices to keysets on the remote, like:
V_db06;T_db06 - and executing these commands in your device selection macro would then automatically call your new multiplexer to set the indexes in your table ?
In other words, the multiplexing is "internal" to the extender and transparent to the user ?

If so - you're right - it would be brilliant if you could make it work.

[vickyg2003]

For us lesser mortals trying to understand this:

Do you mean, this would give 15 devices in the general tab of IR
ie extra 10 devices: db06, db07, db08 etc...

Its more like that a multiplex would multiplex in your keymoves.

I'm basing this on what I've read about what people say about their home theater system For example if you had a blu-ray, a laser-disk, and a VCR stacked on the DVD button, when you'd press the multiplex button the keymove bucket would change for the DVD keys if you specified a different KM_bucket.

You'd set up your 15 devices in IR assigned to any built in/upgrade code.

No this would be done via multiplex. You'd only have 5 devices active at any one time, but you could multiplex out the keymoves, so these would approach being a real phantom, but not quite reach that threashould

You could add keymoves to these devices in IR just like any other device.

You'd be able to pick the db06 for keymoves, and then if the multiplex was picked the keymoves would be active.

Then when programming device selection macros you'd have commands to assign these devices to keysets on the remote, like:
V_db06;T_db06 - and executing these commands in your device selection macro would then automatically call your new multiplexer to set the indexes in your table ?

You wouldn't be able to access them that way, there are not enough keycodes to make that possible. I've run into that wall with the 10820 series. When you need 10 device indexes you can't have very many ht divisions, so with 15 that would be even more.
Actually I hadn't thought about doing any direct access of the phantom buckets. I was thinking if you wanted to access them, you'd need to multiplex over to that device. However, all that would depend on what's available in the keycode list and what you're willing to give up to get 15 KM buckets.

Since I don't have more than 5 devices in anyone location I am having trouble seeing what would be best. I think I'd need to delve into Capn_Trips Atlas IR file in order to see what we're trying to solve here.

[jimdunn]

You wouldn't be able to access them that way, there are not enough keycodes to make that possible. I've run into that wall with the 10820 series. When you need 10 device indexes you can't have very many ht divisions, so with 15 that would be even more.
Actually I hadn't thought about doing any direct access of the phantom buckets. I was thinking if you wanted to access them, you'd need to multiplex over to that device. However, all that would depend on what's available in the keycode list and what you're willing to give up to get 15 KM buckets.

Just thinking out loud...

Could you change the way device selection works in the extender/macros to get over that ?

What I mean is, have a generic V_set command, T_set command etc...,

That way you only need a button for each device (15), and a button for each keyset(5 or 6). That's probably less than there are now with the whole V_TV;T_TV structure.

(it would work pretty much like it does in the 8910 extender)

The (new) V_set / T_set keys etc... would mean: "set this keyset to the current device mode"

(presumably you can read the current device mode from a register somewhere to do this)

Then you can do stuff like

TV ; V_set ; db_06 ; T_set ; P_set ; db_07 ; O_set

which would set volume keys to TV device - Transport and Power to db_06 device - and O_ keyset to db_07.

You probably need some sort of dev_cancel at the end of all that.

I hope I explained that ok.

[vickyg2003]

Could you change the way device selection works in the macros to get over that ?

Remember these buckets are just for keymoves. If you tried to actually change the device index to 5, 6, 7, 8 ..... then the remote would crash. There is probably a way you could get around this but it would be complicated.

The way I was thinking of this working that if in our example,
we had LaserDisk, BlueRay and VCR stacked on the DVD button
the laser disk was set to KM_Bucket DVD, and the BlueRay was set to KM_Bucket db6 and the VCR was set to Bucket db7

Then anytime X_DVD or O_DVD was set, If an O type key was pressed it would automatically check the proper bin depending on the last multiplex. So your Phantom keys would automatically switch. You wouldn't need so many macros, because they would automatically switch for you. If you always did a macro that ended in Phantom1 to do your dirtywork, it would be which KM_bucket that belonged to that multiplex device. Very neat and simple.

If we really needed access to the km_bucket directly we could probably do something like KM_0 .... to KM_15 and KM_Cancel inside macros if you really needed to reach those, but then You'd need to come up with 17 consecutive keycodes, bye bye xshift. I don't think you'd like that.

Edit:
I should probably remind you all that all our special protocols, LKP, DSMs are actually KeyMoves. So if you wanted discrete keys for your multiplexes instead of cycling through them , if you decided to have them in seperate KM buckets you'd need to duplicate those keymoves in each bucket that would be assigned to the DVD key through multiplexing.

[jimdunn]

Ok - I guess it adds keymoves to multiplexing - which is great - because that's one of the big drawbacks to multiplexing.

I was (as you can tell) trying to see a way to make it work like the 8910, but with keymoves for the extra buckets too - largely because I love the 8910 extender - but if the buckets can't be directly selected then I suppose that doesn't work - they'd need to be "real", usable devices.

(given a heap more memory for an 8910 I'd be happy - but that can't be...)

I still think there are a load of keycodes that could be saved in the above way - which would hopefully get over the barrier you keep hitting - and if you were lucky they might be consecutive, too.

I wonder why device selection was changed in this way, to require dedicated set of keys for every device -
(there are 36 of these keys in the Atlas extender, with 5 devices + 1 pseudo(X) - doing it the "old" way you'd need about 12, I think, 5(+1) device selection keys, 6 keyset select keys - and obviously this just gets worse the more devices one adds) -

The new way needs devices x keysets, 6 x 6 = 36
The old way it's 6 + 6 = 12

For 10 devices it's 60 (10 x 6) keys versus 16 (10 + 6), unless I'm being totally thick.

It seems neater the "old" way - and uses far less keycodes - which seem to be a precious resource - but maybe there's a good, technical reason for it.

[xnappo]

I'll mention again the way that RM-IR makes keymoves and upgrades transparent. When you edit a device in RM-IR, it pulls up RM. You then assign whatever keys you want. Shifted keys, imported keys, keys not available for a device mode, and of course keys available in the device mode. Once you hit 'ok' Greg just assigns the keys as needed. They don't show up in the keymoves tab, because the user really doesn't need to know that.

I think with this type of multiplexing available, RM-IR could still handle all of that behind the scenes.

Obviously this would be useful with the normal RM/IR combo too, but it wouldn't be as transparent to the user I don't think.

xnappo

[vickyg2003]

Ok - I guess it adds keymoves to multiplexing - which is great - because that's one of the big drawbacks to multiplexing.

I was (as you can tell) trying to see a way to make it work like the 8910, but with keymoves for the extra buckets too - largely because I love the 8910 extender - but if the buckets can't be directly selected then I suppose that doesn't work - they'd need to be "real", usable devices.

(given a heap more memory for an 8910 I'd be happy - but that can't be...)

I still think there are a load of keycodes that could be saved in the above way - which would hopefully get over the barrier you keep hitting - and if you were lucky they might be consecutive, too.

I wonder why device selection was changed in this way, to require dedicated set of keys for every device -
(there are 36 of these keys in the Atlas extender, with 5 devices + 1 pseudo(X) - doing it the "old" way you'd need about 12, I think, 5(+1) device selection keys, 6 keyset select keys - and obviously this just gets worse the more devices one adds) -

The new way needs devices x keysets, 6 x 6 = 36
The old way it's 6 + 6 = 12

For 10 devices it's 60 (10 x 6) keys versus 16 (10 + 6), unless I'm being totally thick.

It seems neater the "old" way - and uses far less keycodes - which seem to be a precious resource - but maybe there's a good, technical reason for it.

I must say people have wanted 8910 extender behavior quite a bit and I don't understand it. I really should dig out an 8910 and try using that extender. I've got a box of 8910's, but I'm afraid the LCD would be too fragile to survive the things my husband does to a remote, so I've never put them in service.

xnappo wrote:
I'll mention again the way that RM-IR makes keymoves and upgrades transparent. When you edit a device in RM-IR, it pulls up RM. You then assign whatever keys you want. Shifted keys, imported keys, keys not available for a device mode, and of course keys available in the device mode. Once you hit 'ok' Greg just assigns the keys as needed. They don't show up in the keymoves tab, because the user really doesn't need to know that.

I think with this type of multiplexing available, RM-IR could still handle all of that behind the scenes.

Obviously this would be useful with the normal RM/IR combo too, but it wouldn't be as transparent to the user I don't think.

I haven't ever used RMIR. I'm pretty resistant to change. For the longest time I didn't try RM either, and then I was forced to and found that RM can really make some of the compound protocols a lot easier to understand. I should look into RMIR too.

[jimdunn]

I must say people have wanted 8910 extender behavior quite a bit and I don't understand it.

Well, building on what I said above for one example:

Here are very basic, simple macros to set devices up for 3 devices:
(in practice it would probably be more complex - I call LKPs in mine, for example - but for illustration purposes this is it at its most basic level):

Atlas:

TV Key: T_TV ; P_TV ; C_TV ; M_TV ; O_TV ; V_TV
CBL Key: T_CBL ; P_CBL ; C_CBL ; M_CBL ; O_CBL ; V_TV
VCR Key: T_VCR ; P_VCR ; C_VCR ; M_VCR ; O_VCR ; V_TV
____________________________________________________________

8910

Phantom1: SET_VOL_KEYS ; SET_TRANS_KEYS ; SET_MENU_KEYS ; SET_CHAN_KEYS ; SET_OTHER_KEYS ; SET_PIP_KEYS

TV Key: DEV_TV ; Phantom1
SAT Key: DEV_SAT ; Phantom1
VCR Key: DEV_VCR ; Phantom1
___________________________________________________________

See, by making the SET_X_KEYS functions generic, you can use them contextually in other macros - we've already saved 6 keys in macros by the time we reach the third device
(there are 18 in the Atlas example, 12 in the 8910).
And we're only up to 3 devices - by the time we get to 8 we've saved over 20 keys.

It's also easier to maintain this, with Phantom1 as a kind of subroutine, called from other macros.

Imagine you suddenly want AUD to be volume for all devices.

For the Atlas you'd need to change EVERY device key (except AUD).

In this 8910 you change Phantom1 to:

Phantom1: SET_TRANS_KEYS ; SET_MENU_KEYS ; SET_CHAN_KEYS ; SET_OTHER_KEYS ; SET_PIP_KEYS ; DEV_AUD ; SET_VOL_KEYS ;

- that's it, done...

There are lots of other places this is useful too

Plus don't forget we've freed up heaps of keycodes for other use as discussed.

[vickyg2003]

I don't get it, but then I whined openly in the forum when I was trying to get the concept of V_, C_, P_.... Like I said I'll have to see if I can decipher that works by using it.

But still there would not be 15 REAL buckets, only 15 keymove buckets with the keymove associated with the multiplex.

But on thinking about the new version of the multiplex, I think maybe incuding the bound-device as a parameter would make this more user friendly.

The three bytes of data would be
bb bb - setupcode
b - device index 0 to 4
b - km bucket

Then you could change Devices without being in that device mode, so you could have those keymoves setup on a device that was not going to be multi-plexed.

Anyway just brain storming.

[jimdunn]

I don't get it,

The point is that in the 8910 you only have the following macro "keys" for keyset selection:

SET_VOL_KEYS ; SET_TRANS_KEYS ; SET_MENU_KEYS ; SET_CHAN_KEYS ; SET_OTHER_KEYS ; SET_PIP_KEYS

That's 6 keys, and 6 keys only. - no matter how many devices you have.
(you also need DEV_TV, DEV_AUD... one per device for temporary device selection in macros)

They function by
[1] looking what device mode the remote is in
[2] setting that keyset to that device

So
you only use 6 keycodes up in total for these functions
[ii] to use them in macros, you set the device first with a DEV_xxx command, then issue your SET_XXX_KEYS command(s).
(see the example in previous post for how you use this)

So a 5 device 8910, if such a beast existed would have:
6 keyset selection keys + 5 DEV_XXX = 11 keycodes

an 8 device 8910 would have:
(still 6) + 8 = 14 keycodes

a 15 device 8910 would have:
(still 6) + 15= 21 keycodes

_________________________________________________________
In the Atlas you have

T_TV
P_TV
C_TV
M_TV
O_TV
V_TV

that's 6 keys - BUT you have to have ANOTHER 6 KEYS FOR EACH DEVICE, like:

T_VCR
P_VCR
etc...

T_CBL
P_CBL
etc...

etc...


So for a 5 device remote there are 30 of these keys (against 11 from above for the 8910)

for a 8 device remote there are 48 of these keys (against 14 from above for the 8910)

for a 15 device remote there'd be 90 !!! of the little buggers...
(against 21 from above for the 8910)

[jimdunn]

But still there would not be 15 REAL buckets, only 15 keymove buckets with the keymove associated with the multiplex.

But on thinking about the new version of the multiplex, I think maybe incuding the bound-device as a parameter would make this more user friendly.

The three bytes of data would be
bb bb - setupcode
b - device index 0 to 4
b - km bucket

Then you could change Devices without being in that device mode, so you could have those keymoves setup on a device that was not going to be multi-plexed.

Anyway just brain storming.

Yeah - that sounds good.

If you can't have 15 "real" devices (ideal) - then this seems to at least give a way to setup pseudo device selection buttons (like the tune-in keys,) which would work just like device keys.

Not quite as intuitive as "real" device buckets, maybe - but certainly a distinct improvement on the current scenario - especially as the keymoves can be multiplexed.

[vickyg2003]

I don't get it,

The point is that in the 8910 you only have the following macro "keys" for keyset selection:

SET_VOL_KEYS ; SET_TRANS_KEYS ; SET_MENU_KEYS ; SET_CHAN_KEYS ; SET_OTHER_KEYS ; SET_PIP_KEYS

That's 6 keys, and 6 keys only.

They function by
[1] looking what device mode the remote is in
[2] setting that keyset to that device

So
[a] you only use 6 keycodes up in total for these functions
you can use them in macros, provided you set the device first with a DEV_xxx command, and they are portable in that they always act on the "current" device. (see the example in previous post for how you use this)


In the Atlas you have

T_TV
P_TV
C_TV
M_TV
O_TV
V_TV

that's 5 keys - BUT you have to have ANOTHER 5 KEYS FOR EACH DEVICE, like:

T_VCR
P_VCR
etc...

T_CBL
P_CBL
etc...

etc...


So for a 5 device remote there are 30 of these keys

for a 15 device remote there'd be 90 !!! of the little buggers...

Well since this ATLAS is still going to be a 5 device remote, this isn't going to be big deal, but I'm currently working on the 10820n where there ARE 10 real devices. I was hoping to have this out for testing on Saturday, but I think reworking this to have more HT_Categories would be very useful.

Unfortunately understanding that assembler, interspresed among all the paging code is extremely difficult.

[jimdunn]

I agree it's not a big deal for a 5 device remote.

It just doesn't seem to to scale very well.

And trust you to go and quote me during the 10 seconds I had my bbcode tags screwed up for bold
(using as a bullet - not good in phpbb...)

I edited that post again to show how badly this approach seems to scale to larger numbers of devices.

I know it's a labour of love for you - and trust me - what you do is hugely appreciated - I'm just trying to help in my small way by giving another perspective.

It all started when unclemiltie asked for ideas - so blame him
(/me ducks...)