I have a love-hate relationship with the beep function. When I use the remote, I love it, as sometimes remote commands go astray. But it's just an annoyance with front-panel or stalk input (I get tactile feedback from those). But you can only set beeps for home and car power, not for where the control came from.

I'd like to see a simple setting in config.ini to specify which controls cause feedback beeps; default would be all controls as now.

I think that is a great idea, another idea i had would be to also allow the led to blink once when it recieves every ir command.

I second that! Just like a synthesizer recieving a MIDI command, there's usually some kind of visual feedback whenever a signal is received.

another idea i had would be to also allow the led to blink once when it recieves every ir command.

Wow! A simple idea that would be very useful. Just when you think everything has been thought of.

>another idea i had would be to also allow the led
>to blink once when it recieves every ir command.

That would be cool, if it were possible. But Hugo says it cannot be done here

I suppose we could light up a pixel region on the main display, though.

I suppose we could light up a pixel region on the main display, though.

Oh, dude, blink the whole display inverse for each received IR command... That would rock...

Not by default, though. Make it optional, say, with config.ini or something.

Sure.. gimme a sec or two..

Okay. building now. Hijack v272 shortly.

-ml

Okay, just for kicks, install Hijack v272 (available within a minute or two from.. now) and enter this into config.ini:

[hijack]

keypress_flash=1

Cheers

Dude that is so suh-wheet.

It also clearly illustrates the long delay between the keypress and the actual execution of the keypress in the player software... OUCH...

You're right - there really is an amazingly long delay! Ah well. Strange how you don't notice the delay until you see how long it takes for the IR commands to arrive!

A.

Now do keep in mind that the current flash is on "PRESS", not "RELEASE". And the player software generally waits for the "RELEASE" on many/most buttons.

Cheers

Hi Mark.

How about inverting it until a "release" code has been received, but not for more than x seconds (with x being at about the timeout for the press-and-hold functions).

This is just an idea as it occured to me, didn't think much about it, but thought I would mention it anyway.

cu,
sven

Well, the way that it waits for the release is a little ooky, it doesn't really wait for a release code at all, it just waits X amount of time to see if the button is still held down (getting repeat signals from that button) and if not, then it assumes the button must have been released.

Hence our perception that there's a significant delay, because there really is a significant delay. Doesn't matter when you release the button, the delay is the same length of time.

I already put in a bug report (a long time ago) that it shouldn't do the "wait for hold" delay unless it was a function that really did interpret the hold. For example, scrolling left and right in the main menu shouldn't need the delay, but pressing the left and right buttons with no menu showing needs the delay.

Yeah, that's how Hijack implements it's own "short/long" press detection.. only waits around if there's a possibility of a long press being mapped to something.

-ml

>How about inverting it until a "release" code has been received

Hijack v273 is now available with this feature.

Instead of just specifying keypress_flash=1, you can now replace the =1 with larger numbers, representing the maximum number of hundredths of a second you want it to stay inverted.

For example: keypress_flash=100 will hold the inverse display for up to one second, or keypress release, whichever comes first.

Cheers

-ml

Cool, thanks alot.

If we ever meet in person, I will invite you for a nice meal.

cu,
sven

That sounds like fun, but doesn't really address the issue of getting feedback without looking. It helps, though, using peripheral vision.

Yes, I agree. Since we're already isolating IR commands, how hard is it to make hijack beep instead of inverting the display? This would be a nice feature...

Matthew

Simple to add beeps, tough to do it without races (cuz the player s/w may also be trying to do beeps at the same time..).

I dunno, Mark, I had an easy time adding beeps back when I was using Frank van Gestel's IR translation... I never ran into any problems... Is this one of those "1 out of a thousand" race conditions that I might have just not tripped over?

I don't have the source lying around but I got the basic idea from borislav in this thread. Is there a race condition happening there? I think I made some changes to what borislav did, and it seemed to be working okay at the time.

Maybe I'll give beeping a try and if it's working, submit it for inclusion in Hijack. But if there's a race condition in my approach, I won't bother.

In empeg_audio3.c, there is exactly one set of data structures for exactly one beep at a time.

If anything else tries to beep while something is already beeping, there will be a conflict. There is potential for this to produce a VERY LONG beep when the two collide.

The existing standby timer and high-temp warning code in Hijack currently use beeps, blindly, with potential for races. But I'm not too worried about them by themselves, as they are rarely triggered (in beep form), and unlikely (but possible) to cause problems often. This is in no small part due to practically nothing in the player s/w that ever wants to "beep", except for button-presses (which we all turn off, right..).

But having Hijack beep on every keystroke is a much more frequent case, raising the odds a fair amount. Now we would have potential for Hijack to collide with itself for use of the beep structures, as well as with the player software. Ugh.

Like I said, simple (VERY SIMPLE) to do keystroke beeps, basically two lines of code will do it. But much trickier to do it in such a way that we never ever cause mysterious lockups (or just LONG BEEPS).

Cheers