On Thu, Dec 06, 2001 at 08:59:26 -0500, Paul Davis wrote: > > the main area of potential evolution right now concerns the right form > for the argument to lcp_open(). if the GUI's are always on the same > system, which they would be if fork/execed by the host, `pid' makes > sense. but for more generality, GUI's could be started on other > systems (PDA's anyone?) and then sockaddr_in or something similar > would be appropriate.
How about adopting the same approach X uses. unix domain sockets on local machines and tcpip on remote ones, I believe. > in quasimodo, i followed taybin's suggestion of not dictating anything > about the categories a "module" (read: plugin) could claim to belong > to. as long as people are reasonably sensible, and pay attention to > "common practice", this will accomplish the goal richard g. set out. Statements like that go aginst everything I hold true! However its probably best to seperate these issues, as what we really want to do is agree on a useful UI standard, and possibly a way a specifying defaults. > >GOING BEYOND LADSPA > > > >However, Ardour needs a richer plugin API. MN has one. VST has one. > > actually, we don't need one at all. LADSPA is just fine from Ardour's > perspective. The problem here is that plugin *authors* want a richer > plugin API to do their work justice. i think steve is just running > into a brick wall of being unable/finding it very hard to create The UI is the most important issue right now. I can always build things that have large numbers of parameters as JACK applications. > the question has been raised why we don't just do VST ... still, we > faced that one at the same time as LADSPA was developed, and in most > sense LADSPA is still a subset of VST. Out of intererst, how does VST deal with getting large lumps of data to the DSP part? A lot of VST plugins do that, but I don't remeber seeing anything in the API that supports it. - Steve
