Adding 10 devices to an Atlas

[xnappo]

Do I have it about right?

I'll tell you, all of this talk about "buckets" leaves my eyes glazed over, but if I can set up my Atlas OCAP 3033 to have seven or eight functional devices, rather than just five (plus the odd multiplexed one) I'd be one happy camper.

Yes - I think that is right. Again, in my mind you can sum this all up by saying that it should allow RM-IR to build the setup for these 'phantom' devices exactly like it does for a 'real' device.

For IR, this would mean that the output from RM pasted into the 'upgrade' window would also work identically to a 'real' device.

xnappo

[vickyg2003]

We've really digressed here, haven't we? In an effort to bring us back to a practical goal, allow me to be presumptious and summarize what I see as the goal.

As I understand the original discussion, the goal was to get "more devices" available in the extended remote, WITHOUT the limitations and restrictions associated with the current multiplexing protocol(s?).

As I see it, in short those shortcomings are:
(1) PITA to actually switch from one multiplexed device to another. Sure it's a button-press, but setting it up in IR is non-intuitive and then you're still using the same "device" button, but using an alternative buttonpress somewhere - either real of within a macro - to switch;
(2) Multiplexed devices must share keymoves.

What we're looking for is a way to if not in reality, create behavior replicating de facto additional "devices" - with dedicated keymoves, unique dedicated device selection capability, etc.

Ultimately, this would replicate the behavior of "phantom" devices that are present naturally in some remotes (6820, 8820, 8910, etc).

Do I have it about right?

I'll tell you, all of this talk about "buckets" leaves my eyes glazed over, but if I can set up my Atlas OCAP 3033 to have seven or eight functional devices, rather than just five (plus the odd multiplexed one) I'd be one happy camper.

Yep. Ideally we'd have phantom devices, but here we're just talking about a multiplex command that dynamically changes the keymoves while changing the setup code.

So if have devices multiplexed on a button you could elect to have a different set of keymoves swapped in when you change the setup code.

This wouldn't be quite as easy to setup as a true phantom, but a lot more powerful than the current multplex.

The more I look into this, the more doable it looks.

Part of the eye-glazing is that I'm talking on multiple levels. I want unclemiltie to buy into this, should it become possible, because I don't want to have the oddball extender.

Another part of the eye-glazing, is that I'm thinking about how to implement this at the low-level-build-your-own-keymoves level that we'll need with testing.

And then there is the whole user thing, because that's the part that I really don't understand. I don't have a complicated AV system. I needed to use phantom devices to my Comcast remotes, but I don't need to multiplex so you can see where I need to be educated.

[ElizabethD]

Ultimately, this would replicate the behavior of "phantom" devices that are present naturally in some remotes (6820, 8820, 8910, etc).

That's how I understand it as well. You can add 6131 to the list because it has 2 phantom devices added and is as useable as those in 8910.
I suspect that the "bucket" talk we don't understand has to do with the need for contiguous memory space for the real and virtual devices.

I've had problem with multiplexing if the upgrades have keymoves. Was only good for one device with keymoves. Others had to not need keymoves, but maybe Vicky's design is different.

[ElizabethD]

So if have devices multiplexed on a button you could elect to have a different set of keymoves swapped in when you change the setup code.

This wouldn't be quite as easy to setup as a true phantom, but a lot more powerful than the current multplex.

Missed your answer as I was answering CapnTrips. But that multiplexing idea looks interesting. Hope you can pull it off.

[vickyg2003]

Do I have it about right?

I'll tell you, all of this talk about "buckets" leaves my eyes glazed over, but if I can set up my Atlas OCAP 3033 to have seven or eight functional devices, rather than just five (plus the odd multiplexed one) I'd be one happy camper.

Yes - I think that is right. Again, in my mind you can sum this all up by saying that it should allow RM-IR to build the setup for these 'phantom' devices exactly like it does for a 'real' device.

For IR, this would mean that the output from RM pasted into the 'upgrade' window would also work identically to a 'real' device.

xnappo

Xnappo, I can see you are the right person to take care of the RDFs since you are mindful of RMIR.

I can't wait to get this get the thing coded to see if this will actually work. Right now the challenge is to get the RDF tweaked enough to fool IR into letting me load the whole thing into the remote.

[vickyg2003]

Well its no longer theoretical, the remote is very happy working with imaginary devices for the keymoves.

But how on earth am I ever going to explain this, without making everyone's eye glaze over.

[jimdunn]

I'm going to think out loud - so sorry if I make assumptions that don't tie in with how you're doing this - I'm guessing in a few places.

Also I'm talking from an end-user point of view, as a user who uses lots of devices in his setups, so what I'm describing is my ideal scenario from that point of view - I'm hoping it might help, since you said you don't use setups with many devices yourself.

Also, I know it might be more than you're trying to do, here
___________________________________________________________

The absolute easiest way surely would be to have these "imaginary" devices in the RDF, and let IR deal with them the same way it does with any device.

Then all the setup could be done in IR, transparent to the user.

The complication comes that you can only have 5 devices "active" I think - so you might need a separate place to store the indexes the user chose for the "imaginary" devices.

Then your multiplex commands would swap these indices.

In practice it would look to the user exactly like all the devices were just standard devices.

If the user wanted to use, say 8 devices, he would choose 3 keys (maybe A, B, C) as additional device keys.

Then his macro on each of these 8 device selection keys would do whatever multiplexing was necessary to "swap the target device in" to an active register - and then select the necessary HT divisions.
(Hopefully the extender would do this bit "behind the scenes" - so the user would just have to enter one device selection key in his macro)


The problem with everything I just said is that it probably needs the revised way of handling HT keys from the 8910 extender to give you all the keys you need to set up the device macros.

I'm sure there are other problems with it, too - I don't know nearly enough about how the practicalities of storing and swapping the registers and device "bucket" locations would work - so if it's too far from the scope of what you're trying to achieve, I apologise - ignore me ...

[vickyg2003]

Jim while it would be nice to have these be spots that could acctually hold setup codes, I haven't found any way to trick the remote quite that much. In order to get IR to allow these extra devices, I did have to add devices to the RDF and I had to reserve 2bytes per each of these imaginary devices. Those 2 bytes are nothing but place holders. They don't do anything but satisfy an IR requirement to be a device. I don't know how much you've picked up on how hard we extender writers fight for bytes, but I can tell you I look at every piece of code, and arrange anything to minimize every step of code in order to leave as much room as I can, for keymoves, macros and upgrades. So having 22 bytes of codes in an atlas that do nothing but make IR work bothers me.

Each remote has error checking to make sure the device index is in bounds. If you try and use a device outside that limit, the remote reboots. If the coded limit is higher than the number of device buttons on the remote like the 6820, we call them phantom devices.

I can't find a way around the error checking on the device limit, but I can find a way to swap the keymoves when I multiplex.

That being said, here is a little sample of my test data.




In the example above there are two multiplex keys, note that the hex command has an extra byte at the end. One says $33 the other says $3B.
The first nibble is the real device, the second nibble is the where to look at for the keymoves. Note 3 is the normal TV device. B is device i_B.

If no multiplexing has been done, tv, Guide will send 2,3,4
After pressing L1 the setup changes to tv/0054 and the keymoves for real device TV will see the keys that are bound to device i_B.
If pressing tv Guide will send out 6 9 8
if we pressed L1 again we multiplex back to tv/0084 and the keymoves will be the ones that are bound to the TV key.

I don't know this just may be too abstract to even try to implement, but it works just fine.

[jimdunn]

I don't know how much you've picked up on how hard we extender writers fight for bytes, but I can tell you I look at every piece of code, and arrange anything to minimize every step of code in order to leave as much room as I can, for keymoves, macros and upgrades.

I do appreciate that - it's truly remarkable what you do squeeze in.

I'm lucky - I can use "bloaty" code like PHP/JAVA/SQL for what I do

Those 2 bytes are nothing but place holders. They don't do anything but satisfy an IR requirement to be a device....

Each remote has error checking to make sure the device index is in bounds. If you try and use a device outside that limit, the remote reboots.

I can't find a way around the error checking on the device limit, but I can find a way to swap the keymoves when I multiplex.

I thought I'd understood that ok - maybe I didn't

My badly explained idea was that you'd still do what you're doing here - but you would have macro commands that do what your macros are doing
and set the HT mode - so for instance:

device TV is 0001
device i_A is 0002

for a device key to select i_A your macro would look something like

dev_iA ; set_vol_keys ; set_chan_keys etc...
(but this relies on 8910 style commands to have enough commands available)

where dev_iA multiplexes device 0002 onto the TV register (in the temporary HT table you described right at the start - by swapping out a value)
(the extender would be "doing" all this for the user)

That would mean you only ever had to use the 5 real device index values, I thought.

You'd need somewhere in the remote to store the device numbers selected in IR for the corresponding i_ devices though, and I guess that's the problem.

I'm not going to post any more along these lines, though, because I think I'm wandering off too far, trying too hard to turn your Advanced Multiplexing into "real devices" , and the 2 things are different...

Just one last question, though - which will prove I'm not getting it:
you said

Those 2 bytes are nothing but place holders.

Could they still be used to store actual device/upgrade numbers ?

Or is that too stupid, and you didn't mean they were "nothing" in that sense - ie: they hold a pointer or something that can't alter ?

[vickyg2003]

My badly explained idea was that you'd still do what you're doing here - but you would have macro commands that do what your macros are doing
and set the HT mode - so for instance:

device TV is 0001
device i_A is 0002

for a device key to select i_A your macro would look something like

dev_iA ; set_vol_keys ; set_chan_keys etc...
(but this relies on 8910 style commands to have enough commands available)

I understood you perfectly. The reason I called them imaginary devices is because the are not there. Dev_TV is there, but there isn't a dev_iA.

Now one of the things that about the $33 or the $38 in the hexcmd, is that it specifies the real device and where the keymoves will be found. I can multiplex to a device other than the current device.

That would mean you only ever had to use the 5 real device index values, I thought.

On the atlas you only have 5 real devices Dev_auxl, dev_dvd, dev_aud, dev_tv and dev_cbl. the rest of the possble 16 devices are for keymoves only.

Just one last question, though - which will prove I'm not getting it:
you said

Those 2 bytes are nothing but place holders.

Could they still BE actual device numbers ?

Oh I see where you are going with this. You'd like me to build the multiplexer and then multiplex with every button button press.... hmm, I'm hoping you haven't thrown me for another loop here. I'm too tired to think this through..

[jimdunn]

Ok - sorry again.

Just to be clear, though - I wasn't suggesting you'd multiplex with every button press.

My idea was that there would be a command available in macros which does this:

Multiplexes to the required device (if necessary) by reading the upgrade/device number from wherever it was stored - that's why I jumped on the "placeholders" as a place to keep it.
then [ii] sets the right device index (0-4) active

____________________________________________________

If you recall how the 8910 works from the earlier discussion it has a dev_xxx command for every device - and that's how it would work here, except that the command would now do multiplexing as well as then setting the "active" device to apply to the set_xxx_keys commands which follow.

Then you'd use the 6 set_xxx_keys commands as necessary.

Basically you'd create a "Device" button on any button on the remote by constructing the macros like the 8910 section in this earlier part of the thread

So if you wanted 8 device selection keys - you use the 5 that exist - then choose 3 more you fancy and build these macros on them.
_________________________________________________________

It all depends on using 8910 style device selection, though - otherwise you can't have enough selection keys to make it work, as we discussed way back.

And now I've made my own head hurt, too...

[vickyg2003]

Ok - sorry again.

Just to be clear, though - I wasn't suggesting you'd multiplex with every button press.

My idea was that there would be a command available in macros which does this:

Multiplexes to the required device (if necessary) by reading the upgrade/device number from wherever it was stored - that's why I jumped on the "placeholders" as a place to keep it.
then [ii] sets the right device index (0-4) active

Well the problem with allowing the imaginary device to be activated at once is that on an atlas we only have 0-4
If someone did dev_tv, set_vol, i_B, set_chan in our example above where I_b and dev_tv are the same REAL device index

Is now they would expect the vol buttons and the chan buttons to work their expected device. Since the real device on each of these would be 3, you'd have to multiplex between when they pressed vol+ and ch+ to select the right setup code.

Do keep in mind that the advanced multiplex, can be set from be done from another device. Since the hexcmd has the information

____________________________________________________

If you recall how the 8910 works from the earlier discussion it has a dev_xxx command for every device - and that's how it would work here, except that the command would now do multiplexing as well as then setting the "active" device to apply to the set_xxx_keys commands which follow.

Then you'd use the 6 set_xxx_keys commands as necessary.

Basically you'd create a "Device" button on any button on the remote by constructing the macros like the 8910 section in this earlier part of the thread

So if you wanted 8 device selection keys - you use the 5 that exist - then choose 3 more you fancy and build these macros on them.

If I recall that, , yes, I think I can recall that as I've been working all day to implement it.

_________________________________________________________

It all depends on using 8910 style device selection, though - otherwise you can't have enough selection keys to make it work, as we discussed way back.

And now I've made my own head hurt, too...[/quote]


I totally get what you are saying, and in an evironment where I have a little more wiggle room, this would be a piece of cake, but here there are extreme restrictions. I'm not clever enough to figure out a way to do this. That doesn't mean it can't be done. If I were to try and "invent the toadtog" I would tell you that would be impractical too. So someone could come along and see a solution that I can't.

[jimdunn]

Well the problem with allowing the imaginary device to be activated at once is that on an atlas we only have 0-4
If someone did dev_tv, set_vol, i_B, set_chan in our example above where I_b and dev_tv are the same REAL device index

Is now they would expect the vol buttons and the chan buttons to work their expected device. Since the real device on each of these would be 3, you'd have to multiplex between when they pressed vol+ and ch+ to select the right setup code.

Yes - I missed that.

I was imagining that set_xxx_keys could store the imaginary device in the register for the xxx_keyset - but that was me not understanding properly and thinking it through.

You'd then obviously need to check if the "right" device was multiplexed in every time, and swap it if it wasn't - not very elegant at all.

It takes it back to being what you said - checking for, and potentially, multiplexing for every button press - and I'm guessing that might slow stuff down too much ?

Nuts - I really wanted to see a way that might help you use your Advanced Multiplex to fully mimic "real" devices, and I felt like it was just one flash of insight away from being a reality.

Guess it would take a better "flash" than I'm having...

Can't blame a guy for trying, though...

[vickyg2003]

Well the problem with allowing the imaginary device to be activated at once is that on an atlas we only have 0-4
If someone did dev_tv, set_vol, i_B, set_chan in our example above where I_b and dev_tv are the same REAL device index

Is now they would expect the vol buttons and the chan buttons to work their expected device. Since the real device on each of these would be 3, you'd have to multiplex between when they pressed vol+ and ch+ to select the right setup code.

Yes - I missed that.

I was imagining that set_xxx_keys could store the imaginary device in the register for the xxx_keyset - but that was me not understanding properly and thinking it through.

You'd then obviously need to check if the "right" device was multiplexed in every time, and swap it if it wasn't - not very elegant at all.

Actually that's not that big a stretch. Its just the byte count, and finding contiguous variables that makes this difficult.

It takes it back to being what you said - checking for, and potentially, multiplexing for every button press - and I'm guessing that might slow stuff down too much ?

I don't think so, its just how to squeeze it in.

Nuts - I really wanted to see a way that might help you use your Advanced Multiplex to fully mimic "real" devices, and I felt like it was just one flash of insight away from being a reality.

Guess it would take a better "flash" than I'm having...

Can't blame a guy for trying, though...

This is how the changes come about. I'm not saying that this is impossible by any means, I'm saying that I can't see a way to do this. I'm still letting this percolate.

Right now, I'm trying to think if its worth it to include the whole dynamic keymoves or if its an idea that ought to be scrapped.

I am afraid that the whole dynamic keymoves will make my extenders into odd balls that will be difficult to support.

[jimdunn]

Right now, I'm trying to think if its worth it to include the whole dynamic keymoves or if its an idea that ought to be scrapped.

I am afraid that the whole dynamic keymoves will make my extenders into odd balls that will be difficult to support.

If the problems of getting the Atlases to see extra devices can't be solved in the "normal" way - because of the problems you and Unclemiltie described with the data where you would need to change it crashing the remote then your way might be the only way - in which case it's certainly worth it from my point of view.

If we could have "ordinary" phantom devices then you may be right - which would be a shame from the point of view of it being a very ingenious (clever !!!) solution that deserved to work.

I guess you geniuses will have to have a meeting of minds to see which way to go.

I'm just immensely grateful you keep trying, and I hope you realise that.