What new extender feature would you like?

[jeajea]

More device buckets for the Atlas 1056

The ability to increase the key on time – I have a Philips DVD player that I can’t turn off in a macro on an extended Atlas 1056. The same macro works on a non-extended 1056. I tried pauses before and after the off command so I am fairly sure it is a duration/number of repeats issue.

If it is easy more toadtog toggles

[gfb107]

I think he's requesting a feature that I once requested for a URC-6131 extender. The extender turns any long key press into a shifted key press.

See Using LKP instead of shift.

Ah, forget for a moment the way extender writers have to be so terse with their code in order to get it to fit, and the difficulty presented in finding a memory location to keep track the loop passes, and lets look at a few drawbacks to this type of operation.

Well, Hal was able to fit it in the 6131, which I would think has less space available for this sort of thing than the JP1.2 remotes.

1) Sluggish behavior. Its not going to do anything until after you lift your finger or have waited for lkp to timeout.

I think it depends upon the implementation. I would check for the presence of a shifted function (be it macro, keymove, from a device upgrade or built in setup code) before starting the long key press detection. That way you only "pay the price" for detecting the long press when it's actually needed to distinguish a short press from a long press.

2) Problems for some equipment like my TV. When I want to change the volume I need to hold the volume key for quite a while before the volume menu comes up, and then the volume starts to change.

You probably wouldn't want to enable the long-press-to-shift function, and could continue to use LKP where you want it.

3) Counter intuitive for non-tappers. I tend to push the button until I see my equipment acknowlede the push and then lift my finger when I get some reaction like seeing the unit light up to let me know its received the signal. I'd have to totally retrained on remote operation to use this type of remote.

Probably. That's why it could be turned on/off with a global setting. Not everyone would want this.

4) And the difficulty of getting a real LKP macro type key to press. You want Keymoves/macros/Favs to trump a normal keypress, but if you do these tests prior to the timeout, so that you can actually capture these, you have to repeat these tests if it was a long press. Dog slow.

I would not even try to make long-press-as-shift coexist with LKP. It's one or the other, and that should be clearly documented.

Many if these issues were discussed in the original thread, and they were solved.

[vickyg2003]

I didn't realize that it was actually implemented. I've got 6131's at home but I've never used the exender with them. I'll have to give these a look-see when I get home.

[gfb107]

Just remember it's not part in the "normal" extenders. It's only in the special one Hal built for me, linked here

[jimdunn]

More device buckets for the Atlas 1056

Another enlightened voter
But don't forget the 1055 when we've convinced you

The ability to increase the key on time – I have a Philips DVD player that I can’t turn off in a macro on an extended Atlas 1056. The same macro works on a non-extended 1056. I tried pauses before and after the off command so I am fairly sure it is a duration/number of repeats issue.

I agree - adjustable duration for macro keys would be great for those devices that are fussy.

[unclemiltie]

I took a look at more devices for the Atlas family when I did that extender and could never make the remote work. there's something about those bytes after the regular setup that cause the remote to crash. There's also some stuff in the underlying remote that is hard coded to 5 that would need to be worked around. When I first looked at it, it seemed like it would be way too much work. (and the Atlas extender is already a tight fit, but as Vicky said there are other places to put stuff and I could really move things around if I had to)

I see the value of the LKP=Shift-function and could probably make it work. If there's no Shift-function on a key we could just not check for long press. I think I agree that an extender configuration gets either LKP as shift of LKP as a special protocol, but not both. Trying to figure out how to make them co-exist is making my head hurt.

A couple of questions for the extender user crowd:

Some extenders have included the Push/POP function to allow you to push the current device onto a stack, do a bunch of stuff and then POP it back. I've toyed with putting it into the Atlas extenders but never got around to it. (the assignment of the key codes for this and some of the code is actually in the source code but not built in for the released version of the extender right now) Interesting?

I did some stuff in the 15-100 extender to re-do how the remote started up (to enable the clock setting) and could do some similar stuff for the other JP1.3 remotes to allow to set up some stuff on the way up. For example, right now the remote has no way of setting up the default device table for the HT functions. So every time you need to use the remote after startup you really need to press one of the keys that you have defined to set devices up. Is that an issue, should I fix it?

On the 15-100 I also enable a few of the long-press setup features (like setting the clock) selectively. Is there any need for the long-press-setup stuff in the non-display remotes? I never saw a need to enable them.



Keep the other suggestions coming... I'm already thinking about the LKP=Shift . The more that I think about it the easier I think it is since I'm already checking for long-press-shift (to enable/disable backlight on the 1056 and to deactivate the extender on all of the JP1.3's)

[xnappo]

Some extenders have included the Push/POP function to allow you to push the current device onto a stack, do a bunch of stuff and then POP it back. I've toyed with putting it into the Atlas extenders but never got around to it. (the assignment of the key codes for this and some of the code is actually in the source code but not built in for the released version of the extender right now) Interesting?

Eh, not really. I used to use that, but it just got confusing.

More thinking on more devices for Atlas please ! I (probably)have no idea what you mean by 'those bytes after the regular setup' but just from layman's interpretation of what you and Vicky have discussed - maybe it is possible to hijack one of the existing devices and split it up into more?

xnappo

[EDIT] Some further thinking on this. As you may have noticed I have been messing with RM-IR in the last few days. One of the most noticeable differences when you do this is that the difference between upgrade space code and keymoves is totally transparent to the user. Perhaps in a similar way with the combination of extender and RM-IR we could make 'device multiplexer' transparent..?

[Capn Trips]

Since I cannot comprehend and/or visualize what exactly Push/POP does, I can live without it.

Another vote for MORE DEVICES (I know I already voted - but like they say in Russia, "Vote early, vote often!"). Whatever amount of back-breaking, and mind-numbing effort it takes is absolutely a worthwhile investment of your time.

Not sure whether this is a "new" feature for an extender, or for IR, but can there be a way to selectively speed up or slow down individual macros - I guess it can be done with "Pauses" but it is a bit tedious creating the pause keymoves and then adding them to macro sequences. If one could just, while building a macro, have a pseudo-"button" selection of "0.5 sec Pause" to insert into the key sequence would be much more user-friendly.

[jimdunn]

I took a look at more devices for the Atlas family when I did that extender and could never make the remote work. there's something about those bytes after the regular setup that cause the remote to crash. There's also some stuff in the underlying remote that is hard coded to 5 that would need to be worked around. When I first looked at it, it seemed like it would be way too much work. (and the Atlas extender is already a tight fit, but as Vicky said there are other places to put stuff and I could really move things around if I had to)

All joking apart - it really is the single most valuable addition I can imagine to the Atlas 5 device from my point of view. Obviously we can work around it, the superb work you've already done here already makes the extender great on this remote. But, well, you know - 8 would be nice and 10 would be nicer

I see the value of the LKP=Shift-function and could probably make it work. If there's no Shift-function on a key we could just not check for long press. I think I agree that an extender configuration gets either LKP as shift of LKP as a special protocol, but not both. Trying to figure out how to make them co-exist is making my head hurt.

I thought a bit about this - might it be able to be a helper(special) protocol for the extender, and if you wanted to use it you set the device you wanted it on to use this protocol - the protocol accepts the hex for the "real" protocol as fixed data - then it can do its LKP magic and hand off the hex code (or X-shifted hex code) to the "real" executor ?

Just a vague thought...

A couple of questions for the extender user crowd:

Some extenders have included the Push/POP function to allow you to push the current device onto a stack, do a bunch of stuff and then POP it back. I've toyed with putting it into the Atlas extenders but never got around to it. (the assignment of the key codes for this and some of the code is actually in the source code but not built in for the released version of the extender right now) Interesting?

I understand pushing and popping a device in a macro - I honestly don't see how it has a huge value in most setups, though. Sure it's good to be able to branch out to a device, do something, then come back to whatever device you were in and carry on, but I've personally never needed it. It'd be a nice feature but not at the expense of anything else, for me.

Keep the other suggestions coming... I'm already thinking about the LKP=Shift . The more that I think about it the easier I think it is since I'm already checking for long-press-shift (to enable/disable backlight on the 1056 and to deactivate the extender on all of the JP1.3's)

Cool ...

[unclemiltie]

More thinking on more devices for Atlas please ! :P I (probably)have no idea what you mean by 'those bytes after the regular setup' but just from layman's interpretation of what you and Vicky have discussed - maybe it is possible to hijack one of the existing devices and split it up into more?

There are a bunch of bytes in the IR file (on the JP1.3remotes this starts at $60A) that hold the setup codes for the devices. Each setup code is two bytes and on a 5-device remote there are 10 bytes total to hold the setup codes. On some remotes, even though they have 5 device buttons, there are actually more bytes in this area of the remote setup so making more "devices" is pretty easy. For example, the RCA RCRP05 has 16-bytes for setup and thus there are three phantom devices that the remote can use. The way that device selection is done in the bowels of the remote pretty much insists that these devices are contiguous.

On the Atlas, right after those 10 setup bytes there are some other things that the remote uses for something else (that I have not yet figured out) The problem is that if I try to "repurpose" those bytes the remote crashes on startup and the extender never loads. Vicky was lucky in her Comcast extender that the bytes just after the device setup codes were bytes that (1) the extender didn't need and (2) the remote didn't care about. The Atlas, not so lucky.

I was trying to figure out where it crashed and why, a non-trivial task, when I just gave up. But it appears that there is enough interest that I should (some day) take another look. My time right now is limited and I've actually been working on building an extender for the RCA RCRP05 when I get a few minutes free.

[vickyg2003]

More thinking on more devices for Atlas please ! I (probably)have no idea what you mean by 'those bytes after the regular setup' but just from layman's interpretation of what you and Vicky have discussed - maybe it is possible to hijack one of the existing devices and split it up into more?

There are a bunch of bytes in the IR file (on the JP1.3remotes this starts at $60A) that hold the setup codes for the devices. Each setup code is two bytes and on a 5-device remote there are 10 bytes total to hold the setup codes. On some remotes, even though they have 5 device buttons, there are actually more bytes in this area of the remote setup so making more "devices" is pretty easy. For example, the RCA RCRP05 has 16-bytes for setup and thus there are three phantom devices that the remote can use. The way that device selection is done in the bowels of the remote pretty much insists that these devices are contiguous.

On the Atlas, right after those 10 setup bytes there are some other things that the remote uses for something else (that I have not yet figured out) The problem is that if I try to "repurpose" those bytes the remote crashes on startup and the extender never loads. Vicky was lucky in her Comcast extender that the bytes just after the device setup codes were bytes that (1) the extender didn't need and (2) the remote didn't care about. The Atlas, not so lucky.

I was trying to figure out where it crashed and why, a non-trivial task, when I just gave up. But it appears that there is enough interest that I should (some day) take another look. My time right now is limited and I've actually been working on building an extender for the RCA RCRP05 when I get a few minutes free.

Yes with the comcast I was lucky. There wasn't any setting in those 8 bytes that interferred with normal operation.
One thought. Do the bytes after the devices make sense as device codes? Perhaps you could just allow those to be device buckets as long as the user used devices that conformed to the required bit settings and they didn't use multiplex on those devices to push things out of whack?

[xnappo]

Yes with the comcast I was lucky. There wasn't any setting in those 8 bytes that interferred with normal operation.
One thought. Do the bytes after the devices make sense as device codes? Perhaps you could just allow those to be device buckets as long as the user used devices that conformed to the required bit settings and they didn't use multiplex on those devices to push things out of whack?

My that sounds clever! So you mean if by default the bytes had 0x0123 in them you restrict that device to only contain a device of value 291(0x123 in decimal)?

xnappo

[vickyg2003]

Yes with the comcast I was lucky. There wasn't any setting in those 8 bytes that interferred with normal operation.
One thought. Do the bytes after the devices make sense as device codes? Perhaps you could just allow those to be device buckets as long as the user used devices that conformed to the required bit settings and they didn't use multiplex on those devices to push things out of whack?

My that sounds clever! So you mean if by default the bytes had 0x0123 in them you restrict that device to only contain a device of value 291(0x123 in decimal)?

xnappo

Clever, I was going for LAZY! A device bucket is 2 bytes wide, so the chances of them being valid device codes is slim. They also have to be static bytes, not something that's going to be changing during normal operation.

[unclemiltie]

Yes with the comcast I was lucky. There wasn't any setting in those 8 bytes that interferred with normal operation.
One thought. Do the bytes after the devices make sense as device codes? Perhaps you could just allow those to be device buckets as long as the user used devices that conformed to the required bit settings and they didn't use multiplex on those devices to push things out of whack?

Clever but I'm not sure that I want go go there. Try explaining to people that the extra device can only be done via upgrades with specific numbers that by the way don't overlap with any built-in device id's that they're using and that they can't use multiplex on that device. I think it'll create more problems than it solves.

Not only that, but as I said earlier there is some hard coded divide-by-5 logic that I also would have to figure a way to get around.

[ElizabethD]

A couple of questions for the extender user crowd:

Some extenders have included the Push/POP function to allow you to push the current device onto a stack, do a bunch of stuff and then POP it back. I've toyed with putting it into the Atlas extenders but never got around to it. (the assignment of the key codes for this and some of the code is actually in the source code but not built in for the released version of the extender right now) Interesting?

Yes. Very interesting.
But coding the activities that follow might get rough.
I'm trying to imagine how to use. Let's say you did LKP for DVD device, all its associated inputs etc. Push DVD on the stack. Now press Receiver to do some fancy stuff. Pop DVD back in? Is that the idea? If so, LKP vs SKP seems to be doing just that, but I bet there are other uses or ways.

Keep the other suggestions coming...

I'd like to see what was the previous device and/or some flag of the opposite (not TV or not DVD). Because depending what a previous device was or was not, I may need to take some action. No Push/Pop here. Something like, as I do LKP on some device button, if previous device was NOT xxx, run this macro or keymove or if previous device was xxx then do something else or do nothing. Defining what 'previous device' might get very difficult. For me it would be the one before the last LKP on a device button. Currently something of this sorts requires as many toad-tog keymoves as devices, while I think one or two would do the job if I had a flag of this sort. I know this is wordy but I have trouble explaining it even to myself