On Mon, Dec 10, 2001 at 09:22:43 -0500, Paul Davis wrote: [not wanting to iterate over binarries and call --metadata, etc.]
Fair enough, I can see why you wouldn't want to do that, but other people might. Ardour isn't quite as plugin-centric as other apps. > 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 OK, but isn't it fair to assume that all executable files in /usr/local/lib/ladspa/gui/<ID>/* (LADSPA_GUI_PATH or whatever) are frontends? We assume things in /usr/local/lib/ladspa/ and co. are plugins, right? And I think ladspa-<LADSPA_PLUGIN_ID>-<TAG>-x-frontend is necceary anyway, eg. ladspa-1220-default-x-frontend and ladspa-1220-advanced-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 That looks fine. > >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. It can be one way of doing that, infering it from the filename is also valid. > >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> - Steve (picks up Paul and dusts him off). Requiring them the be little endian might be better. The sparc+motorola people can complain about it later ;)
