Subject: Re: [linux-audio-dev] defending simplicity
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Mar 29 2000 - 17:33:40 EEST
On Wed, 29 Mar 2000, Juhana Sadeharju wrote:
>
> In that case host would know what is the used audio format.
> But it should not be necessary to know it.
>
> Having host to know every format mess up the thing, yes.
> But if we move all to plug-ins, then user could just build
> following network to do the thing:
> disk-reader --> 8bit to float --> dsp --> float to 16bit --> disk-writer
>
> The host only schedules this network but doesn't know about audio
> data. This modularizes/separates the scheduler and the audio processing
> a nice way.
>
> It is possible to write some of this functionality to host itself.
> But if LADSPA is designed so that host has to know about audio formats,
> will it cause more mess in my engine?
>
> I think the less messy choise is my approach.
Exactly what you are describing above is possible with my LADSPA
enhancements.
The host has not to know the datatype, it simply can see which kind
of datatypes (by looking up strings) are supported by the plugin's output
and the next plugin's input within the plugin-chain.
If it finds two matching types it can connect the two plugins,
just set up buffers of requested sizes and schedule plugins that's all.
>
> >... and most plugins end up usable only with a limited set of hosts.
>
> That is okay. If one doesn't write host for understanding spectral data,
> it cannot use spectral plug-ins. But if this is done otherwise, one
> could just use those spectral converter plug-ins without understanding
> spectral data.
exactly, as long as the spectral-plugin provides its own custom GUI,
in my model, the host can run it, and just fire up the plugin's GUI.
>
> >Oh yes, we convert it to 26 *mono* streams. That's just what I've been
> >suggesting.
>
> That is my suggestion too. But one could advantage interleaved data
> in efficient recording directly to disk. Keeping LADSPA too simple
> would make that impossible.
LADSPA1 will be simple, but LADSPA2 will follow soon (hopefully) and will have
many nice features, including full LADSPA1 backwards compatibility ,
(that means LADSPA2 hosts will be able to run LADSPA1 plugins)
(hopefully) full VST1 AND VST2 wrapping, that means,
there will be VST headerfiles and a library which will allow allow to
recomplie VST plugins to LADSPA2 plugins which can then run
without any performance penalty under a LADSPA2 host.
Benno.
This archive was generated by hypermail 2b28 : Wed Mar 29 2000 - 19:28:41 EEST