JP1 Remotes

[The Robman]

Would it be possible to make a new version of ToadTog that would be more designed for input tracking? I am thinking of devices that have an INPUT button that toggles between 3 or more inputs. Setting those up in the current ToadTog is really complicated.

Here's what I have in mind.

First, make the register that is used selectable so that that each instance of ToadTog can use a different register. Then you would set up entries for each input giving them a number which represents the number of presses of the INPUT button that are required to get there (from a fixed starting point). You would also need to define the number of inputs so that ToadTog known when to reset the counter.

So, for example, the setup might be:
0 = Radio
1 = TV
2 = CD
3 = DVD
4 = AUX1
5 = AUX2

# of inputs = 6

Then in the ToadTog code, if the user selects the "DVD" input (ie, #3) and the current state is "TV" (ie, #1), ToadTog would send the INPUT button 2 times (ie, 3 - 1 = 2). When the selected input # is less than the current #, it would add the number of inputs (ie, 6) to the selected # first. So, if the user selects "DVD" input (ie, #3) and the current state is "AUX2" (ie, #5), ToadTog would send the INPUT button 4 times (ie, (3+6) - 5 = 4).
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[vickyg2003]

Finding an unused register is very difficult. The remote seems to use them all. At one time i toyed with reusing of the toadtog register to do a case statement type execution instead of the current ticking. Since i use multiple remotes in all viewing areas it isn't feasible for me to put that kind of functionality in the remote.

For the the places where i need that to toggle loop functionality i use LKP recurrsion. It works really well for me.

[The Robman]

Well, if finding an unused register is not an option, what about having the option of using more than 1 bit at a time in ToadTog? In my case, my TV just has 3 inputs (ie, TV/Video1/Video2), so I would just need 2 bits (and I'm using 2 for my hand-made effort anyway. I don't think many devices need to toggle through more than 8 inputs, so they would only need 3 bits.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[tranx]

We have a problem HomeTheatre/BluRay/Receiver Panasonic SCBTT370 which has no discrete inputs, with another box is attached which doesn't cooperate by CEC. Luckily, the 'known state' home screen can be selected with a discrete command and it is also the starting point for input selection from mains power on.

[ElizabethD]

This has been a need since day 1
I have a mad idea, and you're a good protocol maker.
What if you put your inputs on the FAV button (which you now only use for 2 functions). Now, FAV cycles inputs over and over (I know, I've done it), bumping its index. But that's not enough. What if you write a special protocol to change the index that Fav is to use while you synch your devices?
In 1994 .asm I see how FAV runs:
R_FavState = R7E ;Position within Fav list
80D1: 20 7E INC R_FavState
I know nothing. I don't know if you can access $7E in the extender but this would be the place to defeat the automatic INC and make it do your math instead, and stuff it back into $7E.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride

[vickyg2003]

The fav register and the ToadTog registers can be altered in a protocol. There is a limit value too. With PB and the old keymove building spreadsheet you can do a lot with IR. RMIR doesn't allow you to experiment as much. Somewhere in a post I outlined an idea for a SuperTog protocol.

Edit
Here is that old thread on this topic
http://www.hifi-remote.com/forums/viewtopic.php?t=8009

[tranx]

[The Robman]

[pH7_jp1]

In this post: Input Tracking for device without discretes the method identified as "Solution 1" used the state of a key set instead of toadtog bits to track the current input state of the TV. The resulting code was smaller and easier to understand than using toadtog, but it still is a pain to go back and understand at a later date.

Quite a bit later I threw in the towel and applied an inexpensive hardware solution: In this post This worked so well I used it on 2 different systems and the ability to just send discrete codes and not worry about whether the TV was ready to receive an input mode command made it all so simple I quit caring about software solutions anymore.

[The Robman]

I used that old thread of yours as a guide when I implemented my ToadTog solution for my, much simpler, TV. I couldn't use solution 1 because I use all of the buttons on the remote. While my TV does have PIP, I never use it, but I have re-used those buttons in many modes for other things, so I don't have "spare" buttons available. Although, now that I think about it, do the X_ modes include the shifted and x-shifted versions of the buttons too? If so, I guess I could have used one of those. But regardless, I got it working using your solution 2.

Bit 1 = TV vs. VIDEO mode
Bit 2 = VIDEO1 vs. VIDEO2

I can force TV mode using CH+, so it's easy for the remote to re-sync itself.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[tranx]

Supposing the e.g. four inputs are in a loop a,b,c,d..then back to a, which is a common situation:
After synching by whatever means,
the currency of each of four device-modes or activities would imply and that a particular input was already in use.
'a' would correspond to Watch Tv/Device Tv and = the Tv's 'input Tv' (being its own tuner),
'b'= Tv input Hdmi1 (for a PVR)
'c'=Tv input Hdmi2 (for a Media player)
'd'=Tv input Hdmi3 (for DVD player)
Upon that basis, in each device/activity mode, the same single button 'X' could be configured for a different set of three different macros: in each set one macro being on 'X', a second on 'buttonShiftX, and a third on buttonX-ShiftX, to move the input cursor around the input loop as required to achieve the three other possible inputs in the example, while setting up the corresponding device mode/activity which would serve as the next springboard.
In the device mode for watching a PVR, which would correspond to input 'b' and 'recognise' that the PVR mode was current:-
On button X, to go to the Tv mode, the macro would move the input backx1 (or forwardx3) in the loop, to input 'a' (inputTv), with 'ok' as well if needed, and the key/s to set up the relevant device or activity state.
On button shiftX, to go to the Media player mode, the macro would move the input forwardx1, to input 'c' for the media player etc.
On button X-shiftX, to go to the DVD player mode, the macro would move the input forwardx2, to input 'd' for the DVD player etc.
If possible and enough buttons were spare it would be friendlier to use the four device buttons themselves, or the colour buttons, to carry the DSMs, which set of macros would differ as required for each current device state. Three buttons could instead be configured as toggles, to take the remote from a 'home' mode to another or back to 'home' mode from that other device/activity mode (so no need for a fourth button).

[vickyg2003]

[The Robman]

[vickyg2003]

Oh, lol.

I was so used to people not understanding what I'm trying to convey when talking about extenders. I have posted LKP recursion for years and FiNALLY got feedback on this thread

I really like the programming part of JP1. Don't like the hardware aspect at all, but this part is so much fun!