Hijack idea

Tod came up with this idea while we were out to lunch today...

Some of us on the BBS were griping recently about a certain behavior of the buttons on the Mk2 units. It goes like this:

You turn the volume knob so up pops the volume dialog. But now you're done adjusting the volume and you want to do something else, like change tracks. But oh, too bad mate, you can't because if you press left or right it won't change tracks. (Well, the first press doesn't change tracks anyway, it just clears the dialog box. In the old days it was a throwback to the Mk1 where L/R adjusted volume when the dialog was up... at least it now it clears the dialog, which is better than the former behavior, but still not perfect...)

Anyway, to do something else once the volume dialog is up, you have to either wait until the dialog disappears, or you have to press the button twice. Ah, but what if you press the button twice and the dialog has already disappeared, well, then you've skipped twice and that's not what you wanted to do, argh. But if you deliberately wait and watch until the dialog has disappeared, well then where are your eyes? Not on the road, where they're supposed to be, I'll tell you that.

I literally watched Tod taking his eyes off the road and nearly wrecking the car, multiple times, as he struggled with this. Both in terms of switching tracks after a volume change, and also when trying to do the long-down-press to toggle the visual screen on/off after a volume change.

Now, I've argued before that this "feature" should work differently in the Mk2 player software, but the argument of "user interface consistency" was bandied about a bit... well... let's just say the answer was "no" and not revisit that at the moment.

Now here's the fun part: The remote control works FINE, exactly like I'd want it to work. When the volume dialog is up, pressing L/R on the remote simply switches tracks while leaving the volume dialog up just fine. This is GOOD.

Okay... so here's Tod's idea... Can Hijack just detect when the volume dialog is up, and optionally substitute the IR commands when fascia buttons are pressed, for the duration of the volume dialog's lifespan?

Oooo.... Good idea. I do like the new work around where 1 press will remove the volume dialogue box, but this is even better.

Do you want this to substitute ONLY the next/prev track buttons in place of the left/right facia buttons? No others, right?

Do you only want it to do this during the Volume popup, or also during the balance/fader/loudness/... song and dance routine?

Cheers

it's like ordering a cheeseburger and them asking "would you like fries with that?" I love this place

Do you want this to substitute ONLY the next/prev track buttons in place of the left/right facia buttons? No others, right?

Hmm. For me, I'd be happy with just next/prev. However, sometimes you want to do the long-down-press for toggling the visuals, or the short-down-press for opening the menu. Although I can't see how to do either of those with IR substitutions right now. So perhaps L/R is the only thing you can do in that situation.

Another completely different option would be to fudge around with the key events, and just say: "If I get a key event from one of the four buttons while the volume dialog is up, don't eat it. Instead, clear the volume dialog and send that key event to the player after the volume dialog is cleared". This would have the net effect of both clearing the volume dialog *and* making the key do what we intended it to do from the beginning. Although that might confuse some people by pausing the player when they just wanted to clear the volume dialog. So that's not necessarily the best option. So maybe the IR substitution for L/R is still the best way to go.

Do you only want it to do this during the Volume popup, or also during the balance/fader/loudness/... song and dance routine?

I was expecting it to behave the same for any time that dialog was up. Whereever I said "volume dialog" in the original message, substitute "volume/fader/loudness/etc." dialog.


Mark... Thank you for looking at this. YOU DA MAN!!!!!!

Okay, this is 100% untested by me -- that's your job!.

Hijack v326 introduces a new '.V' flag for use in ir translations. This flag causes translations to match only when the player's SoundAdjust pop-up is active;. This is the name I've given to the Volume, Loudness, Balance, Beep, Fader thingie.

This flag has precedence over the '.U' flag, but is otherwise used and calculated similarly.

There's really only one good use for this flag: to solve Tony's problem as described earlier in this thread. In theory, this can be done as follows:

[ir_translate]
Left.V=PrevTrack
Right.V=NextTrack

Please test, and let me know whether it works or not, and whether any other translations still work or not --> particularly ones that use the .U and .N flags.

Hijack v326 will be available shortly.

Cheers

I downloaded and installed V 326, and did a copy-and-paste of the [ir_translate] section you typed above into my config.ini. When Hijack boots, I now get "ir_translate config error" on the screen.

Would it be possible to do something similar such that a translation could exist for when one plays a song or playlist? i would like to be able to remap "play" (short press of the down button when in playlists) into enqueue. could modifiers like the .V be easily developed?

thanks
-ted

Mmm.. okay, it probably works this way instead:

[ir_translate]
Left.L=Left.L
Left=PrevTrack.V,Left.N,Left.U
Right.L=Right.L
Right=NextTrack.V,Right.N,Right.U

I'm not 100% sure if the two ".L" lines are needed..

I love it when things become so abstracted that even the person who develops the feature isn't sure how it works.

Mmm.. okay, it probably works this way instead:

Yup, like a charm. This is actually cooler than I was anticipating, because it both clears the volume dialog AND executes the trackchange command. It also works for fast-forwarding (or seems to, perhaps it would have worked that way anyhow). VERY NICE! THANK YOU!!!

Now, do you think there's a way to format the ir_translate section further so that the top button and the bottom button can work in the same way? In other words, for pause, for menu-open, for long-down-press to toggle visuals, that sort of thing?

Those should work pretty much the same way already. Just do translations for them in the same manner as for the Left/Right buttons..

Yup, tried it. Pretty much worked except for one button which behaved differently than I expected. But anyhoo, this seems to work:

Left.L=Left.L
Left=PrevTrack.V,Left.N,Left.U
Right.L=Right.L
Right=NextTrack.V,Right.N,Right.U
Top.L=Top.L
Top=Pause.V,Top.N,Top.U
Bottom.L=Bottom.L
Bottom=Bottom.V,Bottom.N,Bottom.U

ROCK!!!!

Again, Mark, YOU DA MAN!!!!

Sweet. This works, too:

Knob=PopUp0.V,PopUp0.N,Knob.U

.
Allows me to bring up the PopUp0 menu even when the sound menu is active. Which always happens because I accidentally click the volume up or down a notch when I'm going to push the knob.

Edit: Fixed syntax.

>Knob=PopUp0.V,PopUp0.N,Knob.U

Oh, double-cool! I'm gonna use that one too!

Cheers

Hmm. Riddle me this. I'm tweaking my IR translations a little, and one that used to work no longer works. Here's the relevant section:

AD520C.L=20DF03.L,null
AD520C=null.S

The idea is that the ATT button on my Pioneer steering-wheel remote acted as a "shift" button, but when held down, it put the unit into standby (20DF03 = Source/Power). This at one time worked, and now it doesn't. I can't remember how long ago it worked. I also tried "Power.L" instead of "20DF03.L" and no joy.

Loren has a similar translation documented in the Hijack FAQ:
AD520C.L=play.L,null ; press and hold "ATT" = hush
AD520C=null.S ; "ATT" = Shift Key

Which is basically the same thing, except it should Hush instead of going into standby. This one doesn't work for me either with the most recent Hijack. No idea when this broke, or if I"m doing something wrong... Basically, any time I try to have a long press of a button perform a long press of a different function, it isn't working. Enlightenment, please?

NAw.. it kills the LONGPRESS of the knob. Probably gotta stick a KNOB.L=KNOB.L in front of it.

Cheers

NAw.. it kills the LONGPRESS of the knob. Probably gotta stick a KNOB.L=KNOB.L in front of it.

Oh yeah, sorry, I have that too but forgot to cut/paste it.

Knob=PopUp0.V,PopUp0.N,Knob.U

That is slick. Is there a way at limiting the Select Actions of the PopUp0 menu?

Right now there is clock, knob, visualseek, voladj, shuffle, nextsrc, mark, knobseek, info.

Also, using this currently makes it so that the longkeypress does not work on the knob to access Hijack.

Also, using this currently makes it so that the longkeypress does not work on the knob to access Hijack.

As Mark mentioned (and I neglected to mention, but had in my config.ini) you need to add:
Knob.L=Knob.L

You can configure the PopUp0 menu. Here's what mine looks like:
[hijack]
PopUp1=Tweak...
[ir_translate]
PopUp0=PopUp1,Knob,Info,Visual,VisualSeek,Shuffle,Clock,Mark
PopUp1=Artist,Album,Genre,Year,Swap

That gives you a nested tweak menu, among other goodies. The portion from the [hijack] section renames the PopUp1 menu to "Tweak..." for a nested

See the Hijack FAQ at RioCar.org for more info on how to mess with IR translations.

As Mark mentioned (and I neglected to mention, but had in my config.ini) you need to add:
Knob.L=Knob.L

I just was adding this.

As for the ir stuff.. I guess you learn something new every day... I am on my way to read the Hijack FAQ...

Gracias ynot_...

duplicate post**** deleted***

Rewinding a bit to earlier in the thread:

I'm not 100% sure if the two ".L" lines are needed..

Yes, they do seem to be needed. I tried removing them, and it did not function as expected. In my updated four-button version, it's four ".L" lines, and they all seem to be needed.

But therein lies my question...

The amount of time that it takes for a longpress to be registered seems to double when you use an IR translation like this. Perhaps it doesn't really double, the time for it to register is the same, but then after it's registered, then the IR translate layer has to turn around and send the longpress command to the player. So it seems to take twice as long for the player to respond to that longpress than if the IR translation weren't in place at all. (Once to read/interpret and once to send to the player.)

Can anyone think of a way to write the ir_translate section to work around this additional delay? If not, no worries, because I think that this new code works really well, and I'd happily live with the longer longpresses in order to work around the volume dialog the way it does currently.

Here's a recap of my current ir_translate:

[ir_translate]
Left.L=Left.L
Left=PrevTrack.V,Left.N,Left.U
Right.L=Right.L
Right=NextTrack.V,Right.N,Right.U
Top.L=Top.L
Top=Pause.V,Top.N,Top.U
Bottom.L=Bottom.L
Bottom=Bottom.V,Bottom.N,Bottom.U

The amount of time that it takes for a longpress to be registered seems to double when you use an IR translation like this. Perhaps it doesn't really double, the time for it to register is the same, but then after it's registered, then the IR translate layer has to turn around and send the longpress command to the player. So it seems to take twice as long for the player to respond to that longpress than if the IR translation weren't in place at all. (Once to read/interpret and once to send to the player.)


Well, judging by the nature of the IRtranslate functions, I would really assume this to be the case. Remember that IRtranslate does nothing else but to interpret a button press (read it), translate it into (a) new buttonpress(es) and send the result to the player. Since the player doesn't have "short" press aliases for the "long" press functions, there is no way around this.

The real solution for this would be to introduce new "pseudo" button codes to the player (like it was done for "previous visual"), which do what a long button press would do, but only require it to be short.

If those were available, HiJack could send "longright" (replace by a numeric button code) as a short button press to the player instead of "Right.L".

cu,
sven

Pretty much bang on, smu!

Cheers

Yeah, I figured it was basically that. I was just wondering if anyone had any clever ideas for work arounds.