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
