Subject: Re: [linux-audio-dev] LADSPA 64bit FP support ?
From: Karl W. MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Sat Mar 25 2000 - 22:17:02 EET
On Sat, 25 Mar 2000, David Olofson wrote:
> Yes, obviously you have to get the job done.
>
> But are you going to use another API for price sensitive production
> systems...? This contradicts the whole idea of a standard API, and
> leaves us where we are now - nothing but dedicated, specialized APIs
> that are about as reusable as Microsoft APIs.
What contradicts the whole idea of a standard API? All I am talking about
is that 32 bit floats may not always be the best choice for a given
architecture or situation. I'm not even talking about the API! If
anything I'm arguing for allowing the programmer/user to choose the
performance/quality they want/need in a very broad sense.
> > I was assuming that the host and plugins would be compiled against the
> > same header using the data type specified there. Is there no some type of
> > versioning built-in to the API now?
>
> Does that mean that there won't be development after the 1.0? If not,
> versioning will force everyone to upgrade, or at least recompile
> everything every few months, or alternatively, ignore any new plugins
> or applications.
Huh?
>
> > It seems to me that the general
> > solution would be to check for a API version (v1.1-64 or v1.1-32) when
> > loading plugins to assure both binary compatibility AND data type
> > integrity.
>
> This won't work in real life unless all development is centralized.
> The whole point with plugins is to make things pluggable; not to save
> some RAM through dynamic loading of "built-in" code modules. How many
> versions will there be? Why should people upgrade their code to the
> latest version when it doesn't add any features they need? Can a
> host support all versions without expensive or complicated hacks?
>
Why does development need to be centralized? I am making two assumptions:
1) the api will need to change at some point (hopefully not anytime soon,
but eventually it will) 2) the host and plugins need make certain they are
speaking the same language (ie they use the same API). I was trying to
suggest that there be some means of verifying API version (again,
hopefully it will never be anything but 1.0 but allowing for the future is
what started this whole debate). At the same it would be possible to
check for the float size the plugin was compiled with (v1.1-64 meant v1.1
+ size of LADSPA_Data). I am imagining downloading a host and running
./configure --with-64bit-plugins=true and then compiling your host and
plugins for 64bits. All this could probably be done with a few #ifdefs
and macros. So we are talking about, hopefully, one version. As to your
last two questions, again I am not sure what you are getting at.
> Important point: Who decides what format to use?
>
> (Hint: The user and the developer may not always be the same person.)
>
> Also note that we don't have a $,$$$,$$$ machine to push developers
> and users around to use whatever standard we decide on. They will use
> the official standard, or fork/break the API.
How am I pushing people around? Why do you think this email address is an
alias for Bill Gates? How do any of my suggestions change who gets to
decide which format to use?
>
> > Allowing multiple data types will make both the API and the
> > plugins MUCH more complicated with little gain.
>
> No. I noticed Benno has been working on one solution, and I have
> another one (don't know how similar they are). My solution means no
> more work than for plugins to provide a list of data type descriptors
> for it's ports, and for hosts to make sure not to connect ports with
> different data type descriptors. Here's a snippet from my
> work-in-progress:
<snipped API suggestion>
How is requiring the plug-in writer to simultaneously support seven data
formats not more work for the developer?
> > I can't see adding this
> > complexity just to be able to do conversions (and I can't think of any
> > other use for the multiple types).
>
> Using plugins for different primary target environments, or just
> coded by developers with different ideas. Allowing a set of plugins
> to communicate something that the average host won't understand.
> Using plugins for processing all kinds of signals and data, rather
> than high end audio only.
What type of data can you not transfer between plugins as vector or scalar
floats that the data types that you added will allow?
>
> Is it really a good idea to cripple the API just to remove a few
> instructions from the simplest hosts? Any host that wants to support
> more than one data format will be a lot more complex and messy than
> *any* host for an API that supports multiple formats from the ground
> up.
>
> If you *really* don't want to support more than one format in you
> host, you can just scan * PortDataTypeDescriptors, and refuse to use
> plugins with anything but your favourite data format, rather than
> checking before making connections.
You have it backwards - I want to make it easier to write plugins not to
write hosts. It is a choice between making every plugin potentially do
lots of conversions and handle lots of data types (and there will
hopefully be thousands of plugins) or making a few (or at least a lot less
than plugins) hosts support data conversions.
_____________________________________________________
| Karl W. MacMillan |
| Peabody Institute of the Johns Hopkins University |
| Network and Telecommunications Services |
| karlmac_AT_peabody.jhu.edu |
| 410/659-8297 |
-----------------------------------------------------
This archive was generated by hypermail 2b28 : Sat Mar 25 2000 - 22:45:59 EET