Subject: Re: [linux-audio-dev] LCP v0.1.0
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Dec 10 2001 - 16:12:48 EET
>> Also what seems to be missing is the API part for querying
>> a host for its plugins and the plugins for its ports.
>
>The idea was that the host would be spawning the frontend (GUI, whatever).
>In LADSPA it is fairly simple for a frontend to inspect the plugin to find
>out what its ports are. OTOH it could be a wothwhile addition if we ever
>support frontends to "lambda networks".
More than that: the notion of "generic GUIs" was low on the list of
design inputs. The model was that a GUI is written for a specific
plugin, and thus knows its ports. The purpose of these GUIs is to
provide visual customization not possible when relying on the host to
build a generic GUI.
If the GUI is truly generic, its up to the GUI to interrogate the
plugin (by doing the usual LADSPA stuff) to find out. The host
shouldn't be playing a role in this.
OTOH, I think that supplying the LADSPA plugin ID in addition to a UID
for the plugin generated by the host seems worthwhile, precisely to
cover the "generic" GUI that Steve has described. Such a GUI needs to
know the LADSPA ID of the plugin it will be controlling as well just a
UID for it.
But OTO-OH, in my own head, I see it as the host's job to provide MIDI
control of plugin ports. I don't want to impede an alternate model, however.
As for lambda networks: my impression has been that these would always
be represented as LADSPA plugins themselves, complete with their own
ports, etc.
Also, the more I think about it, the notion of somebody starting up a
GUI that "connects" to an otherwise "hidden" plugin strikes me as
silly. Its a typical geek thing to want to do, but I can see little
real world value in it. The host loaded and runs the plugin; the host
should start the GUI.
--p
This archive was generated by hypermail 2b28 : Mon Dec 10 2001 - 16:10:01 EET