Well, I was thinking of something very very simple, like sound features you find in cell phones. At least just a beep you can set the frequency and duration for various events. En/disabling would be done globally, for whole classes of events, much like you see on cell phones or on the Palm.
But you're right, dealing with .wav or other hi-quality sound is not a PicoGui issue. The day we would want pgserver to play hi-q sound, we could state a sound file name in the .th file (instead of a list of freq+duration pairs as suggested), and pgserver would pass it to OSS or whatever. Pascal John Laur wrote: > > Why not instead of having sound drivers for PicoGUI, you have a sound > server instead - implemented as a client - perhaps with a little > frontend inside of pgl. You would apply sound schemes within the sound > server itself and the sound server would receive messages to play named > sounds (or perhaps it could also receive arbitrary sound data to play > directly) > > ---Is there a way for a client app to trap the widget events from > another client or from pgserver itself? > > If you want to be able to imcorporate sounds into picougi themes, that's > fine but IMO is rather counterproductive to your purpose. Suppose > someone doesnt want one particular button to make a noise but likes all > the other noises that get made -- without knowing how to modify a theme, > the user has no way to disable it on the device without disabling all of > the sounds. I don't really think you gain anything by packing a bunch of > sounds into a .th file vs. a bunch of small .wav files or something > anyway. Sounds are pretty large too, so if you don't want a particular > noise on your handheld, it makes sense not to have to store it there > even when you're never using it. > > In theory, a sound server would also allow for sound mixing, resampling, > multiple formats, et. al. and it would keep the bloat of this kind of > code out of pgserver. > > John > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of Micah Dowty > Sent: Wednesday, October 17, 2001 12:47 PM > To: Pascal Bauermeister > Cc: [EMAIL PROTECTED] > Subject: Re: [Pgui-devel] Sound > > Quoting Pascal Bauermeister <[EMAIL PROTECTED]>: > > ... > > I agree about simple sound vs quality sound. These sounds should be > > handled by the > > server solely, and apps remain unaware of, and I would add the > > possibility to have > > more places where we can attach a sound, like widget click, dialog > > popup, etc. > > That's a good idea. The sound attachments could be defined by the theme, > so that > we could have 'sound themes' with sounds for each widget. Of course > there will > be a config file variable to turn off theme sound :) > > > > > On the other hand I was also mentionning a named sound library > provided > > to > > applications, because I find the theme system extremely well suited to > > manage all > > this in a way that can be customized. > > The only sounds it has so far are 'beep' and 'click', but PicoGUI's > Driver > Messaage mechanism is already capable of allowing apps or parts of > pgserver > itself to tell drivers to play sounds. We would just need to add more > sound > constants, and implement sound playing in some drivers. We would > definitely need > to get sound support into the sdlfb driver for debugging purposes, and > write > implementations for the 68EZ328 and TuxScreen. > > > > > The sound playing engine is of course below Pgui. Remember that the > > console device > > (drivers/char/vt.c if I remember well) can play buzzer tones with some > > ioctl. For > > the sake of simplicity we could start with this device and not care > > about OSS & co. > > That would work when using the framebuffer device on a PC. I don't think > many > embedded systems implement this though, and SDL is easier to debug with. > > > > > Pascal > > _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
