Quoting John Laur <[EMAIL PROTECTED]>: > 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?
There's no way to do this yet... Using PicoGUI's driver messages to play sound is like having an ioctl() on the linux framebuffer to play simple noises. It would only be for simple beeps (keyclick, terminal beep, maybe an alarm) It requires no code in PicoGUI itself, and drivers can optionally implement any subset of these simple noises. For the method of dispatching sounds... a sound server would be nice, but the actual process of dispatching copies of events to it would slow things down. In practice, you'd really only want a couple of types of sounds: - keyclick / tap click- generated when an event comes in to pgserver, might have no correspondance with widget-generated events - another type of click or beep to indicate a button press - Maybe a 'tick' noise when scrolling, resizing apps Implementing the glue logic for this would be simple in pgserver: just add a couple lines of code in widget.c, the button widget, and maybe the scroll and panel widgets to generate driver messages with a sound code from the themes. This wouldn't involve waveform data at all. The method of playing the noise is up to the driver, the driver only gets a number indicating what type of sound to play. > > 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. Well, this would have nothing to do with sampled sound. I agree that sampled sound shouldn't come anywhere close to PicoGUI. But it would be nice to have simple clicks coordinated with GUI actions, so offer auditory confirmation (useful on touchscreens). Lack of fine-grained customization might be a problem, but that's true of PicoGUI themes in general. We could just provide a good selection of sound themes, or have a utility for customizing the theme. I have been thinking about a theme utility, probably in the form of a PGL plugin. It would let you load and unload themes, and provide some measure of customization. For example, it could let you select any bitmap file, a mode (tiled, centered...) and set the background by generating a simple theme in memory. (like the 'customtheme' demo does) You might have something similar allowing the user to enable and disable theme objects within a theme. > 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. Right. Hopefully these sounds would be implemented by the driver in an efficient way. For example, in the TuxScreen the driver could translate the PicoGUI sound codes into the numbers used by the Tux's DSP chip for it's built-in sounds. > > 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. Right, that's what EsounD is for :) > > 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 > > > > > > -- > Only you can prevent creeping featurism! > > _______________________________________________ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel > > > _______________________________________________ > Pgui-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/pgui-devel > -- Only you can prevent creeping featurism! _______________________________________________ Pgui-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/pgui-devel
