What new extender feature would you like?

[unclemiltie]

BTW, there is a practical limit of about 10 devices for an extended remote using the "current" HT setup mechanisms based on key utilization.

Currently, we define 6 keysets (Channel, Volume, Menu, Transport, PIP and Other) and have a set of keys associated with each of them. Each device needs a C_, V_, T_, M_ P_, O_ and X_ command for setting up the HT system the way that we all like. In addition, we need a key for X_Cancel. That's 7 key definitions per device that in reality have to fit into a 64-key block, or one quarter of the total of 256 key definitions (the other blocks are the normal keys, the shifted keys and the x-shifted keys).

Sure you can shift some stuff around but a 10-device with the 6 keysets, the X_ command and X_Cancel needs 71 key definitions. If you have a remote with a "full keymap" of 60 or so keys... well, you can see the math. (In fact, I would bet that a 10-device remote would drop one of the keysets like PIP so it would fit into the 64-key block)


When you start to think about 11, 12, etc, the math is even more against you.

[vickyg2003]

See what Jim just did to me in the other Atlas post. Apparently Nils concurred this for the 8910 and it requires a lot fewer keycodes.

[jimdunn]

See what Jim just did to me in the other Atlas post.

I truly hope you didn't think I was doing anything other than trying to help, Vicky.

I'm sorry if what I posted there caused you to spend any more time on this than you wanted to - I certainly understand how precious time is (I have a 6 year old daughter)

I noticed your post in your new extender testing thread, and I feel a bit guilty that my comments may have impacted things I never intended them to.

I wasn't trying to have any kind of wide impact here - just offering a perspective.

Jim

[The Robman]

I think she just meant that your good idea threw her plans for a loop.

[jimdunn]

I think she just meant that your good idea threw her plans for a loop.

I know - I just didn't want to throw her through any kind of loop.

Now - that woman at the post office who asks for my ID every time when she sees me every 2 days - yes, give me a loop and I'll throw 100/100.

[vickyg2003]

Jim, it did throw me for a loop, but its a GOOD idea. The timing could have been a little better, like about 3 weeks ago , but how could you know that you were supposed to INSPIRE me then All in all, I'm a lot happier to be doing this before it gets anywhere near the public. (I remember when I put out a tester that broke RM) I didn't have a close hold on who had my stuff and every single person that downloaded my pre-beta extender posted about how RM was broken.

[jimdunn]

Jim, it did throw me for a loop, but its a GOOD idea. The timing could have been a little better, like about 3 weeks ago , but how could you know that you were supposed to INSPIRE me then All in all, I'm a lot happier to be doing this before it gets anywhere near the public. (I remember when I put out a tester that broke RM) I didn't have a close hold on who had my stuff and every single person that downloaded my pre-beta extender posted about how RM was broken.

Sorry - I'll try to improve my timing next time.

[The Robman]

Sorry - I'll try to improve my timing next time.

You'd better, because we won't stand for this again!!!

[R2-M0]

I have a feature request. Of course since my remote of choice is the RCRP05B, I'm still (im)patiently waiting for the initial JP1.3 extender port. But while I wait, I thought I'd throw this out there.

I would like an interruptible pause protocol, and here's why... My device macros first send discrete ONs to all the appropriate devices. I then send the input selection commands to my receiver and TV. This way, if my equipment was already on, everything gets set up correctly right away.

However, in case my TV/receiver weren't already on, I insert a pause into the macro to give them time to power up, then re-send the input selection commands. But that means I'm stuck waiting for the pause to complete before I can issue any new commands, even if everything was already turned on in the first place

For me, it would be ideal if I could set up a pause that would immediately stop if I pressed any button on the remote, allowing the rest of the macro to complete, and then finally processing the pressed button.

[xnappo]

I have a feature request. Of course since my remote of choice is the RCRP05B, I'm still (im)patiently waiting for the initial JP1.3 extender port. But while I wait, I thought I'd throw this out there.

I would like an interruptible pause protocol, and here's why... My device macros first send discrete ONs to all the appropriate devices. I then send the input selection commands to my receiver and TV. This way, if my equipment was already on, everything gets set up correctly right away.

Ooo wow! I actually have something technical to contribute for once!

[EDIT: don't try this on the RCA, it won't work - I am looking at how to do it on it. this is for Atlas 3033 only]Try this:

Code: Select all

00 00 01 28 03 C6 C0 3B 0E F6 01 0D F6 40 09 A6
42 01 6B 02 2A EF AF 

NOTE: this is for Atlas OCAP - it is very likely it will not work - if not I can probably get one to work for the RCA but will need to do some consulting with the experts.

I use it for a slightly different purpose. I have a macro for a 3-minute commercial skip on my DVR that does a ffwd,ffwd,ffwd,PAUSE,play where the PAUSE is long enough for three minutes. It was relay annoying if I hit it and it was one of those short commercial breaks, so any key you hit will abort the pause.

Not quite sure this will work for you??

xnappo

[unclemiltie]

Interruptable pause should be pretty easy. I could even put a flag in IR that enabled or disabled the ability to be interrupted. useful?

But I'm working on the Atlas extender with 8910 style HT setup, so that I can then work on more devices for the Atlas extender.

[pH7_jp1]

R2-M0,

I like your idea a lot and may try it myself or certainly after the interruptable pause becomes a reality.

I worked around this problem in a different way as I described in my post in this thread: http://www.hifi-remote.com/forums/viewtopic.php?t=12003

In short, even though my devices have discrete ON/OFF, I use toadtog to track the current state, so I do the pause only when transitioning from OFF to ON. There is an example IR file referenced in that post. Since I am not using toadtog to actually do the ON OFF, just track the state, there is seldom a sync problem and even if one occurs, it does not really cause much of a problem.

[xnappo]

[EDIT: don't try this on the RCA, it won't work - I am looking at how to do it on it.

Here is a version that should work on the RCA:

Code: Select all

00 00 01 28 03 C6 C0 3B 0E F6 01 0D F6 41 89 A6
42 01 6B 02 2A EF AF 

I am not sure that this is the same as what you are looking for though - this is a pause protocol that aborts on any other keypress.

xnappo

[R2-M0]

Here is a version that should work on the RCA:

Very nice! The only way it could be better would be if the button that aborted the pause could be queued up for execution when the macro finished. But even without that little detail, this is a definite improvement.

Much thanks, xnappo!

[xnappo]

Here is a version that should work on the RCA:

Very nice! The only way it could be better would be if the button that aborted the pause could be queued up for execution when the macro finished. But even without that little detail, this is a definite improvement.

Much thanks, xnappo!

Does it not do that? I think on my Atlas it did - but I no longer have the device/setup I used it with so I could be wrong... If it doesn't do it, unfortunately it is beyond my skill level to fix.

[EDIT] After thinking about it - the purpose I was using it for just made it seem like it queued the command. In my macro I used ffwd->ffwd->ffwd->PAUSE->Play. When a commercial was shorter than expected, I would hit 'PLAY' - now in my case, the macro went on to 'play' so it SEEMED to accept the command, when in reality any key would have acted as play.

xnappo