On Mon, 2006-06-26 at 18:05 +0000, carmen wrote:
> > > > To ensure consistency the GUI should get its plugin descriptions from
> > > > the host anyway. This works even with POL (Plain Old Ladspa).
>
> > rather a more general format that it could use to describe its
> > internal modules or other plugin formats as well. The GUI doesn't
>
> in theory, this (client-readable metadata) shouldnt be a selling point. i mean if most hosts provided a nice API to query for plugin parameters. most don't..
For one this is a really complicated thing to do (unless you want to
just fire SPARQL queries directly over OSC which is a bit.. well..
different), and two this assumes the transport is reliable, which in the
case of OSC over UDP isn't true. Trust me. :)
> it would be great for people to be able to make controllers for plugins, without the author of RoseGarden or Seq24 needing to ad some OM-style OSC-query-of-plugin-namespace
I agree, and a good metadata querying system would be a very handy
thing, but the nice thing about the data file is that it doesn't HAVE to
be done that way, and flexibility is always good.
As an example of where this is handy I'm going to do node previewing in
Om's (now Ingen's) load plugin dialog by reading the data file directly.
There's no node to query yet, and instantiating one is no good. There
are solutions (making plugins a first class object and querying that),
but why should the engine have to change to accomodate purely GUI
related features?
Plus, there's tons of other super fun things to be done with all that
tasty graph data client side :]
-DR-
Received on Tue Jun 27 08:15:03 2006
This archive was generated by hypermail 2.1.8 : Tue Jun 27 2006 - 08:15:03 EEST