Rockbox

One other thing - I have no scrollwheel device. This definitely needs testing on such a beastie. I’ve no idea what will happen at the moment (probably lots of unwanted beeping).

Just tried this on my sansa… it only does one click whent he wheel is turned, and i tihnk it actually feels more wierd than if it did click again every time the wheel clicked.

also, the click sound is a bit odd…

The choice of having it click on keypresses (not releases and not
repeats) is interesting. It does make sense in that it better simulates a
kind of hardware / direct physical response. However as I tried it out
(only for a few minutes admitedly) it seemed to me that I might prefer
having it click on actual action events. That way clicks more closely
correspond to recognized events and it less often clicks without a direct
accompanying action. That’s pretty subjective at this point
though. Having it click on events gives blind users an idea of the repeat
rate, might tell you more precisely when a LONG press has been held long
enough, and gives much better feedback on the e200 scroll wheel, although
it’s a bit noisy. In fact, I don’t find it all that useful on most
buttons but I like it on the scroll wheel in particular.

I feel the beep is still not very discreet, so I’ve changed the
parameters to make it more like a click. I’ve also reduced the volume: it
seemed pretty loud to me with beeps set to weak. BTW the beeps/keyclick
options should probably be moved out of the playback menu, and moved into
the system menu perhaps.

Now for the problems:
-The keyclicks are often not played, most likely because of the voice
shutups, in particular when moving up/down a list just fast enough so
items are not fully spoken. The inconsistency of not always hearing the
keyclick is a bit annoying. Perhaps the pcm buffer can be flushed to
prevent this somehow.
-Starting and stopping playback also often interferes with the
keyclick. It’s usually not heard on stop, and it’s paused in the middle
of the click when changing tracks which doesn’t sound too nice. Again
flushing / waiting for the pcm buffer might help?
-I had some weird lockup and/or pcm buffer or voice UI disfunction when
going through values quickly in some sound setting menus or when skipping
several tracks quickly. This may be triggering some race condition… needs more investigation.

In general, I find it a bit noisy, but I do like the extra feedback on
the scroll wheel, in particular on repeat events: let’s you count skipped
items when you move quickly enough that the voice is suspended.

Here’s my updated patch. Now this is modified: triggers on actions
instead of presses and has a more discreet beep sound. So anyone wishing
to check this out should also try the original.

   mykeyclick.patch (2.7 KiB)

Hi Stéphane,

I’ve made a hybrid of the two patches, basically yours but triggering on the initial press only and earlier in the code, so it’s triggered immediately on the keypress, rather than once the action has been determined; that can take a while while it determines between a short and long keypress.

This works much better for me on an H340, but I have no wheel device to try it on; that may make a big difference to the feel.

The setting still needs moving to System and maybe also should update the heard keyclick volume as the user scrolls through the volumes (it will always be one keypress behind, but better than nothing).

   keyclick.patch (2.7 KiB)

Here’s an update that puts the configuration into the System menu, and leaves the old beep setting alone (that might be removable later, of course). There’s an option as to whether repeats should click or not too.

   keyclick_2.patch (14.5 KiB)

I’m stupid. There’s no need to have a separate enable option - the volume control will do nicely.

   keyclick_3.patch (13.7 KiB)

JdGordon reports that this makes a “brain-frying noise” when used on Sansa. Investigation continues as to why, but it’s been tested fine on Gigabeat F20 and Iriver H340.

You have been warned.

iPod testers are welcome!

The nasty noise seems to happen on iPod targets, but seems to be caused by calling pcm_play_data(NULL, non-NULL, 0). :/

This version works around this as I don’t have a PP target to debug this on. It should be fixed properly, of course.

   keyclick_4.patch (14.2 KiB)

Resync (of v3).

   keyclick_5.patch (13.3 KiB)

I cant remember if I told you on IRC or not….
just tryed _5 and the squeel is still there.

this would be a very nice patch. i could help you test also now as i have a ipod video 80gig and a gigabeat F40.

Resync to r15832.

   keyclick_6.patch (13 KiB)

Hi Jerry, yes - testing and feedback would be very welcome.

It should be fine on the Gigabeat, but may cause nasty noises on the iPod Video, like it does on the Sansa. These aren’t problems with the keyclick per se, more that the underlying code doesn’t cope well with short and/or overlapping beeps. Or so I believe…

I’d like to commit this regardless, in the hope that it will inspire someone to fix up the PortalPlayer pcmbuf_beep code.

I think this has to be re synced again because i cannot get it to compile for the gigabeat at this moment.

Hmm, seems fine here, both patching and building for Gigabeat F. What errors are you getting?

could you maybe upload the build here ;) jk for some reason now i got it to work. strange :S

tried it on the ipod. i get the long beeps as well. also my music stops playing whenever i scroll for a long time. maybe like 2 pages.

Resync. I’d REALLY like to commit this, and then hope that the beep-of-doom will inspire someone who knows pcmbuf to fix the PP beep code.

   keyclick_7.patch (13 KiB)

go for it, just put in a nice warning message in the commit message? (or disable it by default)

Resync.

   keyclick_8.patch (12.9 KiB)