Subject: Re: [linux-audio-dev] LADSPA Control GUI metadata
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Dec 10 2001 - 16:22:43 EET
>> how to identify a "gui" is another question. we don't dlopen() them -
>> just fork/exec, so there needs to be a filesystem-based method of
>> identifying them as candidates.
>
>--metadata? Or do you want something that doesn't involve execing them?
i'd prefer it. execing and reading and parsing stdout is a bit more
work than i'd really like to see ...
when i said "identify a gui" i didn't mean "given a LADSPA plugin ID,
find a GUI". i meant "given a directory of inodes, how to tell which
ones might be GUIs". i'd prefer a consistent naming scheme:
ladspa-<LADSPA_PLUGIN_ID>-x-frontend
its not clear how to handle the generic GUI case. the multi-plug GUI
case can be handled with symbolic links, but the generic one needs
both a designator to say that its "generic", and an addition tag in
case you have "steve's generic GUI" and "richard's generic GUI".
ladspa-any-<TAG>-x-frontend
such a scheme allows simple parsing of a loop over readdir(), looking
for ".*-frontend$", optionally enforcing the "-x-" clause for X
Window, and using the filesystem to handle versioning/multi cases.
>> how? using any metadata means either opening a 2nd file to read the
>> metadata, or dlsym-ing to find the revalant symbol. since we don't
>> dlsym GUI's, only the first is really possible, and as soon as there
>> are 2 files, one of them can always go out of sync.
>
>I suggested calling "gui-bin --metadata" and reading stdout for this reason.
>Also works across rsh and ssh if you are spawing on another machine.
sounds fine, but i can't see myself ever using it unless we decide
that this is how we discover GUIs and map GUIs to plugins.
>Which reminds me, do we guatantee endianess of the floats on the wire?
OK, we'll use strings. Or something. Gack. Choke.
--p <falls over, dead>
This archive was generated by hypermail 2b28 : Mon Dec 10 2001 - 16:19:57 EET