dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: The "Loading" splash

Re: The "Loading" splash

From: Stéphane Doyon <>
Date: Fri, 02 Nov 2007 17:08:24 -0400 (EDT)

On Fri, 2 Nov 2007, pondlife wrote:

> Hi Stéphane,
> Excuse me cutting up your post to reply...
>> The clicking might be annoying to some...
> It definitely should be an independent option - the point being to register
> a keypress. This probably depends on your device as much as anything,
> certainly my H340 doesn't have to most tactile of keypads.

Hmm that may be true. I feel my X5 and e200 give relatively good tactile
feedback, except perhaps on the e200 scroll wheel.

But the delay in loading a track doesn't depend on the tactile feedback of
your particular player model.

>> ..., and the wait/loading splash really
>> signifies a longer wait than usual, which I think is a different
> information.
> True, but I'm not convinced it's that useful, purely because it happens
> every time you select a new track, but not (for instance) when you skip
> tracks, even if a disk spinup is required.

Yes, the splash vs the beep. Well perhaps skipping tracks should also
trigger a wait splash then...?

> For me, the entire splash
> (voiced or displayed) is an inconsistent annoyance :-).

So I guess you wouldn't like my suggestion above :-).

Then the opposite: some (as of yet unspecified) audio feedback both on
loading the first track and skipping. And what about the few other
contexts that use LANG_WAIT?

>> If you mean to take out the wait splash completely and replace it with the
>> keyclick, you should probably ask sighted users for their opinion :-).
> Yes, that's my preference, I'm asking for opinion in this thread...!

OK. That wasn't clear from your initial post, and I'd bet lots of people
just stopped reading after the first line or two :-).

> I'm interested in input from blind users mainly, but does anyone else find
> the speech of "Loading" when a new track is selected annoying? Or is it
> useful?
> I'd like to remove this splash, at least whilst music is playing.

Anyway... sorry for being pedantic.

>> IMO hearing the click on each key press builds an expectation of
>> instantaneous response: you're so used to it that you stil feel things are
>> stuck when one particular key press suddenly seems to have no effect and
> I disagree; I find it more a reassurance that my keypress has been received,
> that's all. It's important that the keyclick happens as soon as possible.
> I'd have liked it triggered in the firmware button code, but that's not
> easily possible.

I guess we have slightly different needs. My players give me good enough
tactile feedback. It feels a bit strange when I do a long press to hear a
click and then nothing happening for a while... And to me repeat events
seem interesting, at least on the scroll wheel.

> As I mentioned on FS#7307, I'd like the keyclick to have a
> different pitch for each physical button too, any ideas?

Hmm... Seems to me that's mostly just ear candy... :-) Hmm the only way I
can imagine different beeps for different buttons working out would be to
use multiple tones, say a double beep. Rising for right, falling for left,
same with different notes and greater amplitude for up/down... Something
different for other buttons...

>> ...also, it could be argued that the playback beep
>> and the loading splash are two inconsistent ways of
>> conveying the same info.
> Absolutely; I suspect the playback beep was added for the same reason I want
> a generic keyclick - to avoid multiple skips when there's a delay and the
> user assumes their button press was unsuccessful. IMHO with a keyclick
> option, the playback beep should be removed completely. (There's one

But then people need to have it enabled to get this feedback when
switching tracks, even if they find it annoying the rest of the time and
their player provides good tactile feedback.

> exception; the playback beep makes a different pitch if at the end of a
> playlist, so as to inform that the skip can't take place - that
> functionality could be preserved.)


>> Now I've tried and updated your patch, and will go post comments on the
>> tracker. Will you at least try mine out please?
> Definitely. I'm very grateful that you've synced it. The main problem

Err thanks. I meant to say would you please try out P#8067, just to hear
how it actually sounds. Even if you don't like it, perhaps it'll give you
some new insight/idea.

> remains the effect of fades and pausing, plus it seems you're getting the
> same problem with PCM cut-off as you mentioned with thumbnails. I do think

This needs to work better for me to be able to evaluate it fairly.

I also have an unpublished patch that emits a short beep when wrapping
around or bouncing the top/bottom of a gui_synclist. I like the feedback a
lot, but again the beep often gets cut off partially or completely.

> I'll prefer it not to click on repeat events or key releases (maybe this is
> a wheel vs. button thing), but I'll reserve judgement until I've tried it.

Hmm as a blind user, I might like repeat clicking when scrolling down a
list. I would guess that would be pretty annoying for a sighted user.
Repeat clicking would probably make little sense in some other contexts
like fast forward / rewind, but it probably can't be heard anyway :-). It
definitely needs to be heard on each scroll wheel step. No idea about the
ipod clickwheel though.

Stéphane Doyon
Received on 2007-11-02

Page was last modified "Jan 10 2012" The Rockbox Crew