Hijack v66: context sensitive IR translations

Okay, so I've got two days before I disappear again for several weeks, so I figured I might as well implement another nice feature or two..

Hijack v66 is now out, with a couple of major IR translation enhancements:

-- a button can have separate translations for both LONG and SHORT presses.
-- a button can have separate translations for each active input source of the player (Tuner, Aux, and Main/mp3).

Eg.

[ir_translate]

;Multiple simultaneous translations for TapeSelect button on Pioneer vsx043

00a15e4c.LT=20df07  ; If longpress and Tuner active, then toggle AM/FM

00a15e4c.A=b9461e   ; If Aux active, then select Main/mp3

00a15e4c.M=b9461c   ; If Main/mp3 active, then select Tuner

00a15e4c=b9461d     ; default: select Aux

Or at least that's how it is intended to work. Let me know if you find any bugs that I missed. Note that it is not currently possible to specify longpresses to the right of the equal sign. Maybe someday (non trivial).

Cheers

-ml

Okay, so I've got two days before I disappear again for several weeks


I knew you wouldn't be able to stay away.... And with 2 whole days before leaving, I'm guessing we'll have 10-12 new implementations by that time...

Downloading now...

66 give us a chance i only just figured out how to work 62

Keep up the good work version 62 is great

The original example I posted had the original Pioneer codes wrong, so just for completeness, here is the correct version (for anyone with a Pioneer cu-vsx043 IR remote):

[ir_translate]
;Multiple simultaneous translations for TapeSelect button on Pioneer cu-vsx043 IR remote
a15e4c.LT=20df07 ; If (L)ongpress and (T)uner active, then toggle AM/FM
a15e4c.A=b9461e ; If (A)ux active, then select Main/mp3
a15e4c.M=b9461c ; If (M)ain/mp3 active, then select Tuner
a15e4c=b9461d ; default: select Aux

A couple of things...But first let me say we all appreciate this code!!!

First, if you stack commands to navigate the menu system. Sometimes it won't be just right due to the speed of the commands being issued. I used one that was about seven commands long. About 50% of the time the last Menu/OK command was missed. Not a big deal. But if there were a Pause command, we could have slight pause where we need. Or stack them to have a longer pause when we desired. Example: 00854112=0020DF12,0020DF10,0020DF10,0020DF12,0020DF11,0020DF11,0020DF12 ;EQ
Changed to something like:
00854112=0020DF12,0020DF10,0020DF10,0020DF12,0020DF11,0020DF11,PAUSE,0020DF12 ;EQ

Secondly, Yes I know there is an easier way to the EQ, just using that as an example.

P.S. This is an Alpine remote code.

Mlord, this stuff rules. Not to mention putting the IRTrans stuff in has made my kernel patching a lot easier since I don't have two different patches modifying empeg_input.c now.

I have a wish list request in the IR translation area. I wrote a kernel mod to Frank's original IR trans which allowed me to use one of my remote buttons as a "shift lock" so to speak. Meaning that it would toggle between two different "pages" of translated codes. So on my Pioneer steering wheel remote, I could have normal functions on 10 of the buttons, then hit the "modifier" which would switch those 10 buttons to the numbers 0 through 9. Pressing the modifier again switched back to the normal buttons.

I realize that you have a Long press qualifier in the configs, but I would like to retain the long press functionality of the buttons like rewind, fast forward, "hush" etc. So would it be possible to allow for the configuration of a modifier as I have described? When I did it, I just had it check a toggle flag when translating the codes to determine which of the codes to send. I looked at your code and it looks nothing like the way Frank did it, so I can't use the same strategy.

Let me know what you think... Thanks again. BTW, I anticipate releasing my userland app sometime in the next week or so. It's coming along great so far.

>if you stack commands to navigate the menu system.
>Sometimes it won't be just right due to the speed

Yup, I see that too. I was hoping not to have to fuss with it for now, because the "fix" is HUGE -- it requires a timing queue to be implemented for button presses.

But.. I have given in and implemented it today. v67 now "paces" button presses when feeding them to the player software (let me know if the pacing is still not slow enough -- also, this might still fail if the player waits for the disk to spin up.. dunno).

A side effect of implementing the timing queue is that "LONG" presses can now be emulated as well, using the .L modifier to denote them in the IR translation sequence to the right of the equal sign.

And one person asked for a "SHIFT" toggle feature, so I'ved added that too, using a .S modifier. Any .S left of the equal sign means "do this only if in 'shift' mode", and .S on any value to the right of the equal sign means "toggle the shift mode".

Of course, all of these modifiers may be used in various combinations to really overload the buttons on a remote, so it is important (for now) to specify them in the correct order: .L comes first, then S, then T(uner), A(ux), or M(ain/mp3) (only a single dot at the beginning).

I've also fixed some rather peculiar bugs in the button translation code, so everyone should probably upgrade to v67 or higher.

It'll take a few minutes before the instructions on the web page are brought up to date, but the code is there now.

Enjoy

-ml

I've added the "shift toggle" (shift lock) feature to v67. It uses a .S modifier.

Cheers

So what is your new app? Give us a teaser?

Many Many Thanks!!!

I changed to version 67 and ".L" is no longer working on the left side codes. I can take out the ".L" and the code still works. Am I doing something wrong or is this a bug?

Well "app" is a bit misleading, it's actually a game. Something fun to play while you're sitting in heavy traffic or at a long stop light. Passengers should enjoy it too.

The only thing that I think will be missing from my first release will be a way of saving anything between plays, because that mechanism doesn't exist yet, and I don't think I'm smart enough to implement writing to a raw sector on the disks. Hopefully someone out there is working on this.

Anyone???

Mmm.. I seem to have broken them after testing.. darn..
Wait a few minutes (maybe 30 or so..) for v68

-ml

The pacing is pretty good also. It works about 80% of the time. In a long macro, it sometimes get tripped up. If it could be slowed down a little more that would be better I think.

Well "app" is a bit misleading, it's actually a game. Something fun to play while you're sitting in heavy traffic or at a long stop light. Passengers should enjoy it too.

I know we'll be getting off-topic for this thread, so maybe another can be started. What kind of game if you don't mind spilling the beans?

I was thinking of a couple that would work quite well today: A sideways break-out/arkanoid type game. Allowing to play from the right or left. Maybe letting certain levels flip the sides on you just for the hell of it (difficulty :)

Of course the screen is big enough and the processor powerful enough to do a lot more complex gaming. The controls are about the most challenging for the player. How about a small Karateka? Or Bruce Lee style game? (Think back, waaaay back - from Data East for the Commodore 64 and others)

Of course a cool visualization of stick-men kicking the crap out of each other super-king-fu style would be really nice too (anyone who's seen the flash animations of same will know exactly what I mean :)

Bruno

Can "L" and "S" be used in the same code? That is, can the meaning of a "press and hold" be different depending on the shift status? I'm trying to squeeze a lot of functionality out of my 11 button steering wheel remote :)

Ooo, the screen shape and resolution would be perfect for a port of Karateka....

Ummm I'm keeping the exact nature of the game under wraps because I like surprises. :) It's not an arcade-style game, though. I'm still feeling my way around the graphics libraries and such, so maybe I'll think about those soon.

It'd be cool if bmihulka ported his Emptris to the userland interface. If he doesn't I might give it a whirl after I'm done with my own game.

The main problem I'm having is that the GD graphics libraries aren't too quick. As things evolve it'd be nice if some assembler folks could string together some assembly libraries for graphics. GD works well for me but it's definitely not optimized for the SA1100.

>The pacing is pretty good also. It works about 80% of the time.

I'll slow it down some more by default (v68), and also include a tuneable parameter for you (and others) to play with in config.ini

-ml

>Can "L" and "S" be used in the same code?

Yes. And either/both can also be used in combination with T(uner), A(ux), and M(ain).

-ml

>I changed to version 67 and ".L" is no longer working on the left side codes.

Actually, at least for me, it sort of works.. but I'm doing too much in one breath inside the interceptors, and this is confusing the Empeg code in empeg_input.c.

So I've split things out some more, divying up the workload over time, and empeg_input.c appears to be happier about it. v68 will be out shortly.

-ml

Okay, v68 is out.

Hopefully the .L modifier for IR translations is working better for everyone.

And is it just me, or has this stuff degraded the player's responsiveness to IR codes? Perceptually it seems slower to respond to button presses, even though I have tried flipping back and forth between new/old kernels without any measurable difference.

'Guess somebody's gotta put two players side-by-side, one with hijack and one without, and then hit some buttons on a single remote to see which is quicker..

Last chance for bug fixes .. I'm leaving for three weeks in less than 24 hours from now.

Cheers

-ml

>And is it just me, or has this stuff degraded the player's responsiveness to IR codes?

It was my imagination. I just now set up my Mk2 and Mk2a units together on the table, one with Hijack and one without, and with a single remote (Rio) I sent commands to both units simultaneously. The result? No difference in response speed, except for a very slight lag on short presses of "MENU/OK", which I understand perfectly as a side-effect of hijack having to wait briefly looking for a long press of that button.

So, no difference, no worries.. whew!
(And to think I wasted 2 hours poking at this on Saturday).

-ml

2 hours Mark, you could have realized 3 or 5 fives Versions from 68 to 73.....

Hi Mark,

Two requests. First, any chance there can be a beep (possibly configurable) for each button press? Second, I noticed you change the button codes display to show the pre-translated code. can you change it to show both the pre and post? I think this would help us debug our IR translations.

>Two requests. First, any chance there can be a beep ..for each button press?

Yes, just turn on/up the regular Empeg beep feature.
That is really the only way for the beeps to be even close to being synchronized with the button actions.

>..the button codes display .. show both the pre and post?

Not enough room on the screen. And I think it would be WAY too much code/effort for a non-feature. For debugging, just connect up the serial port and look at the echo-back of the codes that worked. That'll have to do (and it's pretty good).

Cheers

-ml

Tony! This is a GREAT IDEA! If I ever see Karateka running on my empeg I'm going to CRY!

Ok Mark, I tested v69 with my kenwood steering wheel remote, and L does not seem to work. Maybe it is something with the remote itself? Basically, it alsways gets a single button press.
Needless to say, the rest is working perfectly. Now my source button on the remote is working again as I wanted.
Ok, I know everybody told you this, including me , but again, great great job. Thank you!

>I tested v69 with my kenwood steering wheel remote, and L does not seem to work.
Not all remotes (and not all buttons) can actually do "long" presses..
Maybe that's the case here.

In the "Button Code Display" screen, press and hold your problem button. Only one code should appear (once) on the screen, until you release it again.
-ml

I figured someone would dig the Karateka idea. Some otehr titles that would probably do well with the limited resolution and screen dimensions... Choplifter... Kung-Fu Master (this one will be hell on the remote!)... Games running the Infocom text-based adventure interpreter (damned if I can remember the name right now) - an interface could be made to use buttons on the remote to correspond to common keywords (and if you wanted to be really silly you could put a predictive text engine into it, like on the Nokia Phones and similar to what we have for Search in the player software). Temple of Apshai (sort of hack-like dungeon game), Pitfall...

Of course, the ultimate would be to make a simple driving game, like Pole Position. Now that would be irony.

Bruno

The infocom interpreter would be pretty easy to port to the empeg. Problem is the input...

I have to agree with taym on this one. I am using an Alpine remote. It works with long key presses when using v66, but any version after that won't work. So how ever you did it in v66 should be better I think.

taym- try v66 and see if they work there.

If you want to first test the .L in a controlled, known-to-work fashion, then try remapping the nexttrack / prevtrack buttons from the Kenwood or Rio remotes (just for fun). Those buttons are KNOWN to support "long" presses in hardware/software.

As of v68, remapping does NOT work for the Empeg front-panel buttons. I'll reenable that maybe when I get back in a few weeks, if there's any real demand for it.

Cheers

Okay folks.. go into the v69 "Button Codes Display", press and hold the button in question for a few seconds, release it, and email me the last four codes on the screen, along with a description of what you saw happen.

The biggest difference for this in hijack, is that v66 used to track up/down status for each button independently; now it just tracks the most recent button, since the kernel IR driver appeared to also work that way.

Cheers
-ml

Ah.. found it. There was another very subtle difference, which was also a bug.
Fixed, and now tested. Works for me, how about you guys?

v70 is out.

-ml

For those not following the other thread. It works now.

Just for interest, what functions have people coded into the IR hacks?
What macros are people using and can we see them?

Well, all I have done so far is to navigate the menu's. For instance if I want to play all of my rock and roll tunes, they are grouped that way in a play list. One button does it all for me. I have several buttons on my Alpine remote that are unused for anything on the Empeg so I remapped them to do that. With the Long key presses working you can add that functionality to almost any of the buttons though. The only problem is remember what does what what.

I have a Pioneer CD-SR77 which has eleven buttons. The button layout is here. With this IR trans masterpiece, I now have a ton of new functionality. Here are some things I'm doing in mine. Some are enhancements to existing buttons, some squeeze extra functionality out of the measly 11 buttons I have.

---

Shift lock key
My "ATT" button is my shift lock key which toggles the other buttons' state. Press-and-hold this key puts my Empeg in standby mode.

Menu navigation
I have two buttons mapped to "cancel" and "menu/OK" respectively. These along with the next/prev track buttons allow menu navigation.

The poor man's SRC button
I use mlord's example to have one of my buttons act as the one-button source switcher and AM/FM switcher in tuner mode. Since I don't use Aux, it skips over Aux. Also, when in the player, press-and-hold this button does the Rio remote "select mode" button (so I can change Append/Insert/Replace mode.)

Numbers
In shift-lock mode, all 10 buttons correspond to a number. This is something I had implemented with my own kernel hack over top of Frank's IR trans kernel, but it's a lot easier now.

Search macros
In shift-lock mode, press-and-hold certain numbers sends the "search" button several times. For instance, press-and-hold the button that corresponds to number 2 sends "search" 4 times, which will put you in the "search by artist" screen. The numbers correspond to the familiar 2=Artist, 5=Genre, 6=source layout. Some of these aren't working right now but I think that's due to the order I have them listed in the file.

Fine-tuning from the remote
In tuner mode, instead of having my "next" and "prev" buttons send the remote codes for next/prev, I have them actually sending the corresponding front-panel code. This is so that a press-and-hold of the button does fine-tuning of the frequency rather than simply advancing through the presets really fast. So tap next goes to next preset, press-and-hold next scans frequencies as if you had held down the right front panel button.

Volume speed up
I have my volume up and down mapped to a macro which actually sends the button up/down code five times consecutively. When I need finer volume adjustment, I also have the "press-and-hold" volume up and down mapped to a single vol up/down press (actually, to the knob-left and knob-right codes). This is all because the volume change speed is way too slow for me.

Normal functions
I have some buttons normal so that a "press and hold" is truly a press and hold of that button. FF/REW, Info, play, are a few of these. So if I hold down my "info" button I get track details.

---

Whew. I spent a little bit of time on it, but I squeezed everything I wanted in my steering wheel remote in there. The only thing I need right now is a beep when the shift lock is received. I might have to implement that one myself since Mark doesn't want to do beeps.

Anyway I'm attaching the ir_translate section of my config.ini. Feel free to borrow/steal.

Pretty impressive stuff!

For a stale-lover, that is.

Don't get "fresh" with me, Fabris. You who can't eat your Oreos unless they're less than 3 days old. You have much to learn of the virtues of finely aged Oreos.

Games running the Infocom text-based adventure interpreter (damned if I can remember the name right now)

The virtual machine was known as the Z Machine. The term ZIP is also bandied about as standing for Z-Machine Interpreter Program. Whether that means the interpreter itself or the programs that run on them seems to be up in the air.

For more info (I'd like to be more into this than I have the time to be), check out the (unofficial) Infocom Homepage, Inform (if you want to write your own Z-Machine programs), and the Interactive Fiction Competition (if you want to play the best new games).

---

a simple driving game, like Pole Position

Not old enough to remember Night Driver, eh?

Actually, there was already a port of that engine done to the Palm and some other platforms. I think it is (or was) called Frotz. I do not know if it is public domain or not, though...

Author of Pilot-Frotz homepage is here. Free, at least in the beer sense.

No mention of source for the game motor, but source for converting
ZIP packages to pdb is included.

/Michael

Links to most, if not all, Z-Machine interpreters are here. Many of them are open source, including ZIP and Frotz. Considering that one of the design requirements of the Z-Machine was that it be able to run on very low memory machines (remember, this was 1979), it shouldn't be too hard to get one running.

serial joystick?