Subject: Re: [linux-audio-dev] LADSPA 64bit FP support ?
From: Richard Guenther (richard.guenther_AT_student.uni-tuebingen.de)
Date: Sat Mar 25 2000 - 23:23:38 EET
On Sat, 25 Mar 2000, David Olofson wrote:
> BTW, I've been thinking about this LADSPA_TYPE_SIZE thing. What if
> someone wants to pass video frames? Logically, a video frame would
> correspond to a sample, but OTOH, passing video as one (B/W) or three
> (RGB) streams of an integer or float type opens up interesting
> possibilities...
>
> Anyway, the point is that 16 bits for size is a somewhat unmotivated
> figure. Big enough for what most people would call a data element,
> but way too small for a full video frame or some other (probably low
> frame rate) data, like analyze results being passed to the GUI of a
> visualization plugin.
For different data you want to have different protocols with extra
information attached to a per buffer header. It does not make any sense
to feed video data to an audio plugin :) GLAME has a hierarchy of
protocols which either can only differ in the actual type of data to be
transmitted or in the way it is transmitted (control data, f.i. is not
streamed, but rather "out of band", i.e. asynchron to anything else). So
to extend GLAME to do image processing simply define a image protocol as
descendand of an existing protocol (so all plugins that support this
"common" point in the protocol hierarchy support the new protocol) or do
something totally different (which suits the notion of having nodes, ports
and connections, of course).
And yes, GLAME uses lots of #defines and a protocol type mask for this
stuff - well once C++ would be nice :/
Richard.
-- Richard Guenther <richard.guenther_AT_student.uni-tuebingen.de> WWW: http://www.anatom.uni-tuebingen.de/~richi/ The GLAME Project: http://www.glame.de/
This archive was generated by hypermail 2b28 : Sat Mar 25 2000 - 23:56:46 EET