Consistent sound

[Mike C. Fletcher]

Gerard J. Cerchio wrote:
> 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.
I don't want to constrain the student in that way to start.  I expect
them to spend some time figuring out how best to integrate with the
Journal and Bitfrost's restrictions (e.g. symlinks don't work for
material in the Journal), how to specify a collected set of elements
(themes), how to download them, how to integrate the into the user's
existing set of notifications, etceteras.  These are reasonably advanced
University-level students, and they are in a consulting course, so I
want to give them the chance to explore the problem domain and come up
with an elegant solution.

Of course, it could be no student will choose this project, but if we
can get them I think they could learn a lot about what it means to be a
consultant.

Have fun,
Mike
>
> 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
>>
>>   


-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com