Subject: Re: [linux-audio-dev] ladspa gui recap
From: David Benson (daveb_AT_idealab.com)
Date: Thu Jun 01 2000 - 18:30:29 EEST
On Thu, 1 Jun 2000, Paul Barton-Davis wrote:
> >I don't think this is totally implausible: the plugin
> >format in this case is an elf-binary-executable and a protocol for
>
> this is a violation or at best a real stretch of the current LADSPA
> standard, which says that plugins are dynamically loadable objects. it
> just so happens that for linux/gcc/gnu-ld/dlopen right now, dlopen
> happens to work on an elf executable too, but that was not true once
> and it may not be true again.
>
Hey, I'm just saying it is a possibility once we get
to the phase of designing "gui-per-plugin threads".
I wasn't even trying to mean a dlopen of an elf-exe,
rather a fork/exec(). The gui-plugin (separate from
the dsp plugin) would be an elf-executable, a standalone
program that knew how to talk to a ladspa-gui-host over,
say, stdin/stdout using the ladspa-gui-protocol.
This *does* have the advantages of
- letting the *plugin* determine the gui to present
- making the interface fairly definable
- all the random advantages of process-per-gui models:
cpu competition, isolation from the host (for stability) etc.
So I say: this *is* a viable choice in the
thread-per-plugin-native-gui situation.
However, I obviously think this whole idea of "plugins choosing
their own toolkit" to be pretty restrictive to the host.
- dave
This archive was generated by hypermail 2b28 : Thu Jun 01 2000 - 19:37:04 EEST