Consistent sound

Gerard J. Cerchio gjpc at circlesoft.com
Sat Nov 24 10:49:04 EST 2007


Mike,

This looks like 1000% more than what I was suggesting and I am all for it.

I would like to make a implementation suggestion. To keep this all 
simple I suggest the student use a naming convention either directly to 
the sound files or as symbolic links to the sound files in a single 
sound localization directory. so emote( laugh, 6 ) would play the sound 
file linked to laugh.6.wav in the the localization directory. Of course, 
the type of media file would be able to vary to anything there are 
standard players for in the OLPC. So laugh.6.gif would be selected if 
the machine was in silent mode. Perhaps if the laugh.gif is just a 
single simple image the intensity can do a animation with the image to 
indicate the intensity.

Mike C. Fletcher wrote:
> The basic concept seems to be that of a "system notification", as seen
> on all modern desktops.  We'd need to integrate with Sugar and Bitfrost,
> and implement the generic emotional notifications for games and the
> like, but otherwise the implementation should be quite familiar.  That
> should make it fairly straightforward to implement.  I have a request
> from a "consulting" course at U of T to act as a client on a project for
> one of their students.  I'll propose this as the project if people are
> amenable.
>
> Assumptions:
>
>     * DBUS Interface
>           o This lets non-python activities use the same interface
>           o Python wrapper can be provided
>           o A pipe-level interface might also be useful for games
>             written by new coders (open pipe, write "happy 2.5s\n")
>     * Sugar Control Panel extensions to customise the sound-scape for
>       each user (just think how quickly many people just *have* to shut
>       off the Windows start sound)
>           o Alternately, a GUI on the daemon that allows for customisation
>     * Visual Notification options when muted
>           o For the deaf/hard-of-hearing/classroom use
>     * Severely restricted environment for the daemon/service
>           o Access to sound files, preferably just those in the default
>             set(s) plus those explicitly loaded by the user into the
>             application's work-space via the configuration tool
>           o Access to sound hardware
>           o Access to current volume setting (read-only, likely)
>     * Support Localisation for default sound-sets
>     * "Classic" Notification Set (window actions, system
>       startup/shutdown, that kind of thing)
>           o Likely taken from an existing free-software system to start
>             quickly
>     * Emoticon Notification Set (emotional content, e.g. for games) with
>       intensity setting
>     * Sound implementation(s)
>           o GStreamer sources
>                 + OGG files
>                 + Wav files
>           o CSound scores
>     * Visual notification implementation
>           o Will require some coordination with the Sugar peoples to
>             provide a non-obtrusive "overlay" notification mechanism
>
>   




More information about the Devel mailing list