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-