Well, they weren't really broken on the standard remotes, but "long" IR button translations with .L should be working now in v70. After seeing reports of compatbility issues with v66, I looked harder at the code and found/fixed a timing error that affected the .L detection.

New in v70:

-- .L actually works in IR-translation macros
-- read/check temperature every 4sec instead of every 2sec.
-- fixed bug which caused unpredictable invocations of inittherm(),
it should now get called only about once every 5 minutes or so.
-- added a button-event counter to the "Button Codes Display" screen.

Any more bugs? Please make an extra special effort to thrash at this release over the next 16 hours or so, cuz after that you'll have to wait until (almost) Christmas for fixes from me.

Any Kiwi's in the crowd?

Cheers.

-ml

You da man! The long press works again on my Alpine remote. Just in time. I am on a long road trip tomorrow. About 12hrs.

P.S. Have a good trip.

>You da man!

Thanks for re-testing so quickly, Dude!

Cheers

-ml

Thats what I'm here for.

Yes,
We have at least one Kiwi here -
I'm a Kiwi - you going to be down this way then?

I live in Auckland as does JazBZ [or whatever his name is].
If you're going to Kiwiland then we can maybe catch up sometime - email me at [email protected] and we can set something up
[or just reply to this post]

I'm running V62 right now of the patched kernel but I'll have v70 by nightfall.

Regards

Mark,

I noticed (at least on my steering wheel remote) that in many cases the press-and-hold doesn't actually respond until you let go of the button. This is different than the behavior of the standard remote. Like, if I define a press-and-hold sequence, it won't execute until I let go of the button, instead of executing as soon as a specified interval elapses.

Any thoughts?

Ok, so I confirm that the two buttons SOURCE and PAUSE on the Kenwood remote do not support logn press at all. It is clear in the IR code detection in HiJack. Now, I am going to reprogram one fo the other buttons and check if that works.

Another Kiwi here - living in Germany at the mo though.

>if I define a press-and-hold sequence,
>it won't execute until I let go of the button

The way it works is, when you press the button, the translation waits to see if you are going to hold it for longer than one second. After one second, it says "aha! long press", and then sends the translation sequence of press/release codes, except for the final "release" code. When you let go of the button, the final "release" code is then sent. I figured that this might be more useful to people, but that was just my guess.

I can change this behaviour, and simplify the code in the process, if we all agree on it. It's actually more complex to implement the current behaviour than the alternative you seem to want.

Cheers

-ml

Well... I'm just used to the way it works on the Rio remote where the press-and-hold command is executed as soon as the "long press" timeout has elapsed, rather than waiting for the user to let go. I don't have a one-second timer in my head so it's sometimes hard to know when I can let go of the button.

Maybe it could be configurable? Is there anyone who likes it the way it is now?

>I'm just used to the way it works on the Rio remote

But.. but.. that's exactly the same way the translations do it!
(or at least that is how the code is supposed to be doing it).

Perhaps here it's just a matter of the particular player function responding differently? Try programming an alternative longpress to do exactly what an existing Rio longpress does.. same behaviour?

If the translator were to NOT hang onto the release code until the user lets go, then how the heck could anyone map buttons to do "fast forward" or "fast reverse" ??

Regardless, I'll add something to change the behaviour for some situations.
Perhaps a .I modifier on the macro definition might do it?

Cheers

Oh, wait.. I get it (at last they say!).

The issue here I suppose is that macros which don't end in .L are effectively being forced into .L. Right? Got it.

This is an artifact from before we had .L capability on the right of the equal sign.

Okay, now that I finally see the real issue, I can fix it.

Thanks all!

-ml

Well okay here's an example from my situation. I am using a long press of my "shift lock" key to put my Empeg into standby. Here's the relevant definitions:

[ir_translate]
; The shift key
AD520C.L=20df03.L ; press and hold "ATT" = standby
AD520C=FFFFFFFF.S ; "ATT" = Shift Key

When I hold down the button, my Empeg doesn't go to standby until I release it. I agree that for FF/REW, it makes sense to hold onto the release code. So maybe it should be configurable with a modifier as you have stated. Unless I'm doing something wrong with the above definitions... There are other buttons I have which have the same behavior, such as the AM/FM buttons:

AD520D.LT=20df07 ; AM/FM in tuner

This one doesn't execute until I let go of my "source" button. Are you seeing the same thing with any of your remotes?

>When I hold down the button, my Empeg doesn't go to standby until I release it.
>I agree that for FF/REW, it makes sense to hold onto the release code.
>So maybe it should be configurable with a modifier as you have stated.

Okay try v72 and see if it works better for you.

For the case where you end a macro with a .L button, but don't want it to hang around for the final button release (ala FF/REW), then just add another "dummy" button press to the end of the macro. Specifically, 0xffffffff can be used as a "dummy" press (it is never passed on).

Okay?

-ml

Actually this one isn't working well. The press-and-hold functions like FF and REW aren't working as they should. Holding them down acts like a "tap" so it goes to the next track instead of fast-forwarding, for instance. Similarly, holding down the button I defined as "info" doesn't go to "details" like it did.

There is some interesting behavior I noticed with this one though.. A "tap" of my ATT button toggles shift lock as expected. And if I hold it down for about two seconds, it correctly goes to standby. However, holding down for about a second and releasing it changes sources from player to aux (I don't have that defined in my ir_translate section anywhere.) So there are actually three functions depending on whether I tap, let go after a while, or hold it down for about two seconds. Was that intentional?

>The press-and-hold functions like FF and REW aren't working as they should.
>Holding them down acts like a "tap" so it goes to the next track
>instead of fast-forwarding, for instance.

I'll bet you have defined them in the wrong sequence in config.ini:
The .L translations must preceed the non .L translations..
I had the same error in my config.ini file until a few minutes ago,
and it really confused the heck out of me while testing..

-ml

Well, I didn't actually have a .L translation for my FF/REW button. I do have "LS" translations for some macros (Long press while shift lock active) but as for un-shifted, here's what I have:

AD5242.M=20df10 ; Prev Track / Rewind
AD5243.M=20df11 ; Next Track / Fast Forward

In previous versions I didn't need explicit .L translations. I just added them and FF/REW work, but the delay seems significantly longer. Like with the Rio Remote's FF/REW there seems to be a 1s delay, with v72 it seems to be 2s.

Yes, it will be exactly 2sec, a side effect of implementing your previous request.
Unavoidable, too, with the RIO codes.

But.. if you use the Kenwood codes for FF/REW, these will work without the dummy code, as in:

AD5242.LM=b9460c.L ;Rewind
AD5243.LM=b9460b.L ;Fast Forward
AD5242.M=20df10 ; Prev Track
AD5243.M=20df11 ; Next Track

-ml

Ooopps I goofed on the FF code, here are the correct codes:

AD5242.LM=b9460c.L ;Rewind
AD5243.LM=b9460d.L ;Fast Forward
AD5242.M=20df10 ; Prev Track
AD5243.M=20df11 ; Next Track

Hmm actually I think you meant b9460d (AM button) for fast forward. That seems to cut the delay in half (as expected.)

So it sounds like if there is a 1s delay for an overloaded button like FF, REW this delay becomes two seconds.

My Info button is defined like this:

AD5241.L=20df14.L ; info
AD5241=20df14 ; info

When I tap it, I it acts like info. When I hold it however, it changes the info after one second, and then shows track details after two seconds.

So I guess what I'm saying is that maybe the side effects of this implementation outweigh its advantages... Maybe it was a bad idea?

Yeah. I'm going to revert the behaviour back to what it was before.

If you want a longpress to release without waiting for the actual button release, just append a ffffffff code to the tail end of the macro, as in:

xxxxxx=yyyyyyy.L,ffffffff

Okay?

Okay, v73 is out, with some minor IR translation changes and other fixes.

Please read the ir_translate notes on my website for exact details (and examples).

http://rtr.ca/empeg/

Have a great next 3 weeks, everyone.

byebye..

I don't know what's scarier... The fact that Mark has been posting and updating all the way to the last minute.... Or the fact that if he didn't go on vacation, he could probably double the amount of work he's already done on this project. :) Seriously, go back and look at the release history as it's been posted here. He's a machine!

I hope the vacation gives you a much deserved break. But if you feel some inspiration for a revolutionary new feature while on that 5.13b, don't forget to chalk-up, whip out a pencil and jot it down. :)

Bruno

I tried v66 (have not tried v71 yet). I received an error when syncing the config file (timed out)

Had the following as a test:
[ir_translate]
00aa550f=0020DF12

What did I do wrong?

In reply to:

---

I tried v66 (have not tried v71 yet). I received an error when syncing the config file (timed out)

Had the following as a test:
[ir_translate]
00aa550f=0020DF12

What did I do wrong?

---

Probably nothing. Try it again (maybe the empeg decided to do a filesystem check that time..)

-ml

for Christs sake pack for the trip or something! You're getting me nervous.

The Alpine is that way.

Mlord is probably gone, but I want to report that when you're in the equalizer screen, and you tap the knob, it brings up the VolAdj. Oops. You don't want that to pop up in the EQ.

Calvin

Can anyone confirm my observation that hijack's BINDBUTTONS ioctl always intercepts (hijacks) the top front-panel button (IR_TOP_BUTTON_PRESSED)? I am seeing this with my EmpTriv game and in some other stuff I'm working on. I'd like to leave this button unbound but I can't seem to let it pass through to the player.

It would make sense if it did from mlord's point of view as he uses it to exit any of his menus.