Subject: Re: [linux-audio-dev] plugin questions
From: David Olofson (audiality_AT_swipnet.se)
Date: ma loka 11 1999 - 18:47:05 EDT
On Mon, 11 Oct 1999, Andy Lo A Foe wrote:
> We are at point in AlsaPlayer development where parameters for the various
> plugins (input, output, scopes) need to be created/preserved :-)
> One of the ideas that have been floating around the mailing is to let the
> plugins return a LIST of parameters they have. A parameter can be for
> example a string, float, int, color, etc. A parameter should also have
> optional constraints tied to it (int, floats can have ranges). This will
> allow the application to build its own User Interface -> flexiblity.
> (I realize of course that not every plugin will be able to communicate its
> parameters easily this way, room should be left for plugin specfic widgets
> for example)
On the contrary, I'd suggest that event types are restricted to as
few as possible, and preferably, they should even have their ranges
defined in the API spec.
Why?
Well, it doesn't matter much to a generic GUI, and not too much to an
automotion system (sequencer) either. But it *does* start to get
messy with user defined ranges when connecting plug-ins into event
processing networks. Adapting the output events to all sorts of
inputs...
<philosophy>
Of course, this depends on what the system is going to be used for.
However, I usually try to design this kind of things with OS design
philosophy in mind - keep it clean, layered and reusable. The "hack
one API for every new situation" philosophy (empowered by a certain
company in particular) is useless in the long run, at least when
trying to design something *useful*.
</philosophy>
> > Hmm, why don't we just use a typedef that is required to be
> > a floating-point type. 32bit machines can use floats while
> > 64bit machines (and precision-freaks) can use doubles or even
> > long doubles...?
>
> Is it that simple? Changing the type might also change the min/max values,
> or require another algorithm for better accuracy!?
Another point, apart from the compatibility one I made before... High
accuracy + high speed processing *does* involve careful selection of
temporary register/variable sizes, and ordering of operations, even
with FP. Perhaps not a big problem in most cases, but it exists, and
may matter quite a bit in some extreme situations.
//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
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST