Subject: Re: [linux-audio-dev] ladspa gui recap
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu Jun 01 2000 - 17:06:52 EEST
>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.
but you are requiring that a host investigate the format of the
plugin, or the presence of a "main()" in the plugin. not only that,
but your scheme is also creating a tangled web: the plugin must
contain the run() and runAdding() functions, which execute in a host
thread, but you're suggesting that there is other stuff there that is
executed in a new process.
we've already suggested allowing plugins to be associated with
standalone GUI processes, so this is possible, but it should not
happen by including this in the "plugin file".
thats what the catalog that david has proposed is for.
>ps. in xaos i believe it:
> - looks for DISPLAY
> - checks for linux console + permissions to set graphics mode (svgalib)
> - uses curses interface
>i think autodetection of libraries is really pretty easy;
>far easier than supporting the library in the first place.
what you've described isn't close to adequate for the GUI system we've
spoken about. it works only on the assumption that all the GUI's are
in standalone processes. this is a bad idea, even if allowing *some*
to be is not a bad idea.
--p
This archive was generated by hypermail 2b28 : Thu Jun 01 2000 - 18:00:46 EEST