Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: [l Re: Plug-in API progress?
From: P.J.Leonard (P.J.Leonard_AT_bath.ac.uk)
Date: ke syys   29 1999 - 10:42:58 EDT


David Olofson wrote:
>
> On Tue, 28 Sep 1999, P.J.Leonard wrote:
> [...]
> > There are 3 options here.
> >
> > 1. server sends events to notify GUI of changes.
> > 2. GUI asks the server it's current state.
> > 3. Mixture of 1 and 2
> >
> > (1) Is conceptually more attractive but you run the risk of clogging
> > the system up
> > with event messages if you have fine grain controllers changing fast.
> > Here I speak from
> > my own experience (I have Qt widgets for adjusting midi parameters I
> > also map midi controllers
> > onto parameters and monitor the state with the sliders). The pitch
> > change wheel generates
> > quiet a lot of events !!!)
> >
> > (2) requires the GUI to poll the server on a timer which is a bit ugly
> > but reduces the
> > time spent doing X11 stuff. I update widgets every 1/10 of a second. You
> > can change
> > the pitch wheel from min to max in this time.
> >
> >
> > I think any system should allow both schemes (1) and (2).
>
> ...or you could have the engine keep track of time (which it is doing with very
> fine accuracy all the time anyway), and start to thin the event stream to the
> GUI elements. GUI elements could tell the engine how high event frequencies
> they want to handle. Could easily be done per GUI element if desired.

<start of 2 cents>

 Yes, I think a design goal should be make things as simple as possible.
But
also as flexible as possible. I guess we should really have a wish list
and
see what scheme is the best balance.

 I am assuming the engine model is a network of components each with an
artbitary number
of input and output ports. Ports could be for signals, controllers or
monitors.

 Engine components.

  Treated like black boxes. They export a list of input and outputs
(ports) with names and types.
This would allow a generic type of GUI interface to control a new black
box. OK if you
know what all the things do you can design a fancy widget but let people
create engine
components without the pain of doing a GUI (in any case the GUI flavour
of the day tends
to change rapidly).

 The main engine component (hub) would provide an interface for create
instances of components
and connecting them together. I guess we need to register components
with hub that then provides
the user with a list of available components. Again this could be done
in a generic fashion
(just rules about what types of connections can be made with other
ports)

 By defualt all engine components would broadcast events at top speed. I
would implement
your frequency filter with another engine component that had a fast
input but an output
that broadcasts the last value at user defined rate (keeping the job of
the main elements
simple).

<end of 2 cents>

-- 
 Cheers Paul (P.J.Leonard)                                        

Tel: +44 (0)1225 826108 Applied Electromagnetic Research Centre, Fax: +44 (0)1225 826305 University of Bath, BATH. BA2 7AY UK


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST