Re: Sound effects

[Lennart Poettering <mztabzr 0pointer de>]

On Fri, 12.12.08 02:00, Iain (iain gnome org) wrote:

> Some thoughts on sounds.

Here's my response as one of the guys who wrote the specs and as the
one who implemented them. I'll probably repeat a lot of stuff other
people said. Sorry for that.

1. This should be discussed on the xdg mailing list.

2. I think you underestimate how many people use event sounds. Since I
   started to hack in this area I am actively noticing that
   surprisingly many people enable them, including the input feedback
   stuff. And not just crazy people but also hackers at
   conferences (i.e. tech people!). Please note that I don't use event
   sounds that much myself, and
   a year or so or two I didn't think *anyone* would. But I was
   wrong, people use them, although the ones we used to ship are quite
   annoying. While most sounds are used only by a minority, sounds for
   email, IM and suchlike are used by huge majority of people,
   especially when they use non-Linux OSes.

   On Operating Systems like MacOS where the shipped sounds are high
   quality a lot more people leave them enabled. In Windows this is
   similar, although the sounds are worse quality. Heck, some sounds
   (like the Windows startup sound) even entered pop culture in a
   way. Finally, don't forget things like the venerable MS Plus! which
   included theme sets which included sound themes.

   Also, don't forget accessibility.

   Just because you don't use them you should not assume nobody
   does. Because that is simnply wrong.

3. I know of at least 3 sound themes right now. Our upstream version,
   a Mandriva theme and some Ubuntu "Human" stuff.

4. You can easily coalesce multiple event sound files using the dash
   notation, as pointed out by Marc-Andre. Even if we list 125 sounds,
   that doesn't mean you'd have to define them all seperately. Also note that the new
   sound theme dialog coalesces quite a few of those events into
   one. And it is intended that way: the set of event sounds generated
   should be extensive and the meta information about each event
   should be verbose. However, only a subset of these sounds should be
   exposed in the config UI or defined in the themes. How fine grained
   this is chosen is left to the UI or theme designer.

5. libcanberra support slipped in in the last GNOME version as blessed
   dependency very very late. Only a minority of programs use it right
   now. Don't expect an adoption from zero to 100 in no time.

6. The 125 sound names don't come from nowhere. We looked around on
   the Internet for sounds that are already in use. i.e. the sounds
   Windows defines, GNOME defines, MacOS defines, KDE defines. The
   sounds different applications define, and sounds people have publicly
   requested. For almost all sounds listed in the spec there is at
   least one pre-existing example where it is used or
   available. Please note however, that we only included sound names
   that made sense to us. So if you do the full survey again, you
   might end up with substantially more than 125 sounds.

   And again, just because we list 125 sound, it doesn't mean you have
   to actually define them all. You can easily coalesce them due to
   the aforementioned dash notation.

   Also note that some people mentioned that they thought the icon
   naming spec was handled too conservatively. We explicitly want to
   be a bit more liberal about what we include in the sound spec and what not. (Of
   course we won't include *any* random bullshit people ask for...)

7. You claim the list is too large but incomplete at the same
   time. Sure it is incomplete . We are happy to add
   more entries when they make sense. The barrier is low for new
   additions.

8. In contrast to what you claim it is dead easy to create a sound
   theme. Simply base your work on the fdo theme and replace the wave
   files. A monkey on a donkey could do that. Of course you can do it
   more elaborately than that if you wish, but you don't have to.

> With sounds like window-new, window-move-start, window-move-end,
> window-minimized, window-unminimized will the computer ever be
> silent?

You can disable any sounds or subset of sounds you wish.

The KDE sounds for these specific events are very subtle btw. w-m-s
for example is both very low in volume and frequency and actually
pretty good.

> There is a principle applied to dialog boxes, called the butler principle[10].
> When there is a knock at the door, the butler doesn't ask if he should
> answer the door, he goes and does it.
> He also doesn't tell you that he's going to do it, he just does it.
> I think this should be applied to sounds as well as dialogs.
> If the butler requires the master's attention, he does it subtley,
> making a discrete *Ahem*
> not by screaming "HEY I NEED TO TALK TO YOU!"

And so? Of course it's fine to define themes that are subtle. However, if
your hardware is breaking or suspending failed while you closed your
laptop an annoying sound is more adequate.

> The sound theme spec[3] defines four[see footnote 4] categories;
> Alert, Notification, Support and Game.
> I think these 125 sounds spread over the 4 categories can be reduced
> to a single sound [5].

That my friend is ridiculous. 

Are you aware that I find it quite informative if can discern the
sound that is played when a CD is finished burning from the sound I
get when I get a new mail? 

> Firstly the Game category can go. Its not really sounds for games
> anyway, its sounds for card games.

How did you come to that conclusion? Because non-card games know no
winners nor losers?

> Secondly, throughout the other 3 categories, the sounds are either
> a) Very application specific (i.a. the camera sounds, the phone sounds)
> b) State the obvious (i.a. lid-close and lid-open. I know I've closed
> the lid, I don't need to be told about it[7])

Stuff like power-plug and unplug is certainly not obvious. It's a
warning sound.

You are excessively oversimplifying this.

Also, maybe the next time you take part in the discussions when we
first asked for comments about this, instead of raising it after we
already pushed through with everything.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4