Subject: Re: [linux-audio-dev] we should use gtk objects for our plugins
From: David Olofson (audiality_AT_swipnet.se)
Date: to elo 26 1999 - 22:57:20 EDT
est_AT_hyperreal.org wrote:
(...)
> Using the gtk object system for our plugins might be best of all. It
> provides a C-based object system with wide use and multi-lingual
> support. Note that gtk objects (as opposed to widgets) have nothing
> X-windows-specific about them. I'm pretty sure this approach could be
> Audiality-friendly, for example.
As long as it means that we can have full control of memory allocation,
and make sure there are no system calls involved, yes, it could work
with Audiality. Everything that's declared *must* be explicitly provided
by the host, or we have no control over portability. (That is, no
portability.)
A hard real time environment will always be very different from a normal
environment, and a plug-in API for real time plug-ins must follow the
rules of real time programming for there to be any point with it. (That
the API might be possible to implement on the "structures & calls" level
in a certain environment isn't enough for real time.)
> Interested parties should look in particular at gtkobject.[ch],
> gtktypeutils.[ch] and gtkarg.[ch]. Doesn't it look like a plugin API?
> :) We need only make a domain-specific sub-class.
>
> What do you think?
Some interesting reading in there, but IMO, it's too complex as a
foundation for a real time audio plug-in system, while not specific
enough to help us very much. It's designed to handle the complete object
oriented complexity of GTK+, while we need little more than a single
level of classes and a basic way of handling instances.
And BTW, no, I'd never consider C++ for DSP plug-ins. 90% of the C++
style OO features are far beyond what we need, and C++ style virtual
function calls generate slower code than C style OO. This becomes very
significant when buffers are 8 samples at 44.1 kHz, which you'll easily
get with Audiality real time mixing + monitoring, or within feedback
loops.
This also applies to the gtk stuff. Too many levels of indirection, and
too much complexity already, and we'd still have to add stuff.
I think we should do this from scratch, concentrating first of all on
getting good performance in the main data paths and the frequently used
subsystems. Then we could add extensions we need, as far as possible
without loading the main paths with conditionals and multiple
indirections. Flexibility is good, but if it costs too much, it's
pointless. The Linux kernel coding style rules.
//David
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST