Subject: Re: [linux-audio-dev] LADSPA Finalisation Deadline
From: Karl W. MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Sun Mar 26 2000 - 22:34:58 EEST
On Sun, 26 Mar 2000, Juhana Sadeharju wrote:
> >From: "Richard W.E. Furse" <richard_AT_muse.demon.co.uk>
> >
> >I'm proposing finalisation of LADSPA version 1. This would give a solid
> >baseline for programming, possible further development and/or possible use
> >within MuCoS.
>
> What I write below might already been fixed. At last when I read you
> LADSPA was simply ruined. I have some latency in mailing.
>
> About this precisions issues and LADSPA:
>
> I simply don't understand why it is so difficult to include different
> types to LADSPA.
>
> There would not be any problems because we would have plug-ins
> which converts from one type to another if needed. I don't support the
> idea of Benno that some code would be automatically inserted to host
> for conversion. If one writes a plug-in set which needs to use 256-bit
> numbers, the one would also provide the needed conversion plug-ins.
> (Or writes that 24-channel interleaved audio plug-in.)
>
Again, why would you need to do this. Anything is possible - people could
pass audio data between plugins as wordperfect 5.1 documents - but there
is almost no gain from doing this and a lot of expense. If someone can
provide one plausible scenario where this would be a big gain for an audio
plug-in I will shut up and go back to fixing Windows 2000 :) The
interleaved plug-in is definitely not a gain. The 256-bit plugin - if it
has conversion plugins on either end to convert it back to the suggested
32bit float format - might as well do the conversion internally.
> Task of making sure the plug-ins fits together is of a flow network
> builder, not the engine's. Therefore we could use strings for the types
> in case one wants to add new types without the need to update LADSPA.
>
What would the strings be? This would result in a lot of incompatible
conversion plugins as far as I can tell. And isn't a host, in the simple
case, a 'flow network builder' and an 'engine'? Would the host compare
the strings returned by plugins to determine compatibility? I must be
misunderstanding part of your suggestion.
> If one has a plug-in which is cabable of processing many types,
> user explicitly uses the conversion plug-ins to choose the appropriate
> type if it is different from the input signal type. Otherwise the input
> signal type counts.
>
> A plug-in will output the type what is at input (except some special
> plug-ins).
>
Unless the special case is used this ends up with a lot of extra plugins
in your network doing nothing useful at all.
> Transmission lines between plug-ins transmit byte streams, so, anything
> can go through.
>
In the normal case nothing is transmitted - the ports point to a buffer
created by the host. It is important to remember that the host has to
create the buffers. Assuming the plugin says that it can't process data
in place and uses a format smaller than the largest format known to the
host I guess things could be made to work. What is the plan for handling
these buffers - it all seems so messy to me.
I know everyone is tired of listening to me talk about this (and I am
tired of writing about it) - let's make a decision. I'd say freeze the
api for a while, let everyone write some plugins and then hopefully get
congress to approve it (this is a congressional committee right?).
Karl
_____________________________________________________
| 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 : Sun Mar 26 2000 - 23:01:39 EEST