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: David Olofson (audiality_AT_swipnet.se)
Date: ke syys   29 1999 - 18:23:56 EDT


On Wed, 29 Sep 1999, P.J.Leonard wrote:
[...]
> > ...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.

Yes. The most important part of this effort would be to find a pattern in the
list of desired features, and implement *as few subsystems as possible* to
provide these features. I've seen too many things designed the other way
around... (Creeping Featurism.)

> 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.

Something like that, yes. (The design I have in mind at least.) There's
basically two data types: Data streams and events.

Data streams are just raw data, transfered as variable size buffers (although
the buffer size is normaly kept constant for audio plug-ins). Kind of like a
low level networking protocol, optimized for high bandwidth real time streaming.

What's more interesting to the UI is the event system. If I understand you
right, signals, controllers and monitors make a subset of the events I intend
to send through my event system. (It'll also handle some or all of the plug-in
<-> host communication, even during instantiation of plug-ins.)

The subclassing of events is one area where I really would like some ideas -
what do we need, and how to standardize as much as possible without making it
useless? The idea is to be able to use defined standard events (as opposed to
custom events that only a plug-in and it's GUI module can understand) for
almost everything, so that an automation system or preset librarian could
really work in real life. I don't want to force plug-in writers to do that kind
of work, as it really belongs in a central system. Extra interface layers ==
overhead, complexity, more work, more bugs, less plug-ins...

> Engine components.
>
> Treated like black boxes. They export a list of input and outputs
> (ports) with names and types.

That would translate to things like "I use Standard Level Control #1, and I
call it 'Threshold'." Nothing much more will be needed, and other parts of the
system (like an automation GUI) will know what a Standard Level Control is, and
how the user would most likely want to see it on screen. More importantly,
things like importance of control "signal" quality and other factors can be
predefined, so that you don't need masses of conditional code in the engine, or
extra plug-ins to interface to the control.

[...]
> 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)

This is where restrictions of buffer size, data format, sample rate etc should
be taken into account, so that the engine can group plug-ins efficiently, and
throw in converter plug-ins where necessary. (No code for this inside the
actual real time engine, that is.)

> 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).

Yes, that's _exactly_ how things are to be done using my idea of an design.
Frequently used "system" plug-ins can be built into the engine, or even
hardcoded inline, but they should still act and look like normal plug-ins in
most respects. No extra APIs for "special functions", that is. And *everything*
can be automated, monitored or whatever, using the same code... (Ok, no rule
without exceptions, but at least, we can try to do most things right from the
start. We have seen enough of Redmond style design, right?)

//David

 ·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
    ·Rock Solid David Olofson:
    ·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
    ·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
    ·Open Source ·Singer/Composer


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