Subject: RE: [linux-audio-dev] MuCoS, Glame, API Issues
From: Richard Guenther (richard.guenther_AT_student.uni-tuebingen.de)
Date: pe maalis 10 2000 - 04:57:45 EST
On Fri, 10 Mar 2000, David Olofson wrote:
> On Thu, 09 Mar 2000, Richard Guenther wrote:
> > On Thu, 9 Mar 2000, Alexander Ehlert wrote:
> >
> > > Hi,
> > >
> > > > > It would be no problem to introduce a property, where the plugin actually
> > > > > defines the datatype it wants to use and the host would have to do the
> > > > > right conversion. Wouldn't complicate ladspa too much I think.
> > > >
> > > > Uh, no - better use floats everywhere, _if_ conversion is necessary just
> > > > create a conversion plugin.
> > >
> > > wouldn't be possible as ladsa plugin though.
> >
> > Why? This is then very limited!? Is it only because with ladsa there is no
> > way to tell that the resulting buffer is not float?
>
> I think the point was that if plugins cannot support other formats
> than float, some *other* kind of plugins would be needed to do
> conversions.
>
> Normally, with a plugin API with only a single format, the conversion
> would be done either by the host, or by some different kind of
> plugins. Personally, I don't fancy either of these solutions. I want
> the API to be usable for this kind of work as well, as it is a quite
> important and non-trivial part of the signal chain. Enabling next to
> *all* signal processing to be done in plugins allows for very simple
> host implementations, *and* o lot of user level flexibility.
>
> > > > Its definitely not possible to wrap around such a plugin inside glame
> > > > without breaking all the fun stuff of glame. You can of course set up
> > > > all the plugin in one thread, and everytime copy glames buffers to
> > > > LADSPAs DataLocation. But as I said in my previous mail - this "how
> > >
> > > Hmm, I think you could just give the ladspa plugin the address of one of
> > > our buffers...
> >
> > Hmm, yes, probably. But I dont understand how the ladsa buffers are
> > associated with the modification of data.
> >
> > Is it
> >
> > buffer1(read) --- plugin --- buffer2(written)/buffer2(read) ---- plugin
> >
> > as I understand or is buffer1 identical to buffer2?
>
> This is a choice the host can make depending on what the current
> processing net looks like. Plugins don't have to bother with it
> anything more than either supporting in-place processing (most algos
> inherently do), or saying LADSPA_PROPERTY_INPLACE_BROKEN.
So a plugin that supports inplace modifying still needs to support the
case of non inplace modifying? Err...
Richard.
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST