Re: [linux-audio-dev] LADSPA 64bit FP support ?

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

Subject: Re: [linux-audio-dev] LADSPA 64bit FP support ?
From: David Olofson (david_AT_gardena.net)
Date: Sat Mar 25 2000 - 22:26:27 EET


On Wed, 22 Mar 2000, Erik Steffl wrote:
> I am new to the list and I've been following only last few days of the
> thread so this is more of an outside opinion then insight:
>
> you don't want to be stuck with one data format in API specs.
>
> no matter how good the data format is, sooner or later you will need
> different data format (no data format is good for everything). I think
> that sooner or later you (or somebody else) would like to have
> compressed data format. I assume that plugins are network transparent
> (either that or plug-ins ARE the network) - right? in some cases you are
> going to operate via limited bandwidth...
>
> of course, it makes sense that in most cases plugins will use the
> default data format (whatever that will be).
>
> all above IMO, of course.
>
> while we're at it - where can I get more info about these issues? for
> example - are plugins strictly audio only or are they going to be used
> in more general sense (for example midi etc.). as far as I can see there
> is no reason not to be prepared for any streamable data. after all a
> stream is a stream is a... am I too of the tangent here?

Well, MIDI-like communication between plugins and applications is
what the MuCoS event system is all about... As for data types, my
idea is that the basic API should carry only buffers of void data,
where the byte size of one element is specified as a part of the type
ID. (See my earlier mail.)

I'm thinking about passing something like that LADSPA_Type_BufRef
(from my earlier post) through control and/or signal ports, but I'm
not sure where to put the type of the data in the buffers. I don't
like the idea of one LADSPA_Type_BufRefSomething for every one of
these types...

Perhaps one bit in the data type descriptors should be reserved to
identify the type as "buffers of this type" rather than "elements of
this type". Makes no difference to hosts that don't want to deal
with the details of data types, it allows all defined data types to
be used in this way, and it eliminates the recursive "BufRef to
buffer containing BufRefs" thing.

//David

.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'


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

This archive was generated by hypermail 2b28 : Sat Mar 25 2000 - 23:00:50 EET