JP1 Remotes

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

[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]

[jimdunn]

[vickyg2003]

[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]

[jimdunn]

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

[jimdunn]

[jimdunn]

[vickyg2003]

[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 [b ] 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...)