14 May
2004
14 May
'04
7:20 p.m.
On Fri, May 14, 2004 at 08:10:32PM +0100, Steve Harris wrote:
On Fri, May 14, 2004 at 07:07:59 +0200, Fons
Adriaensen wrote:
For this application, I'd very much like to see something based on OSC,
or a subset of it. After all, we're dealing with sound plugins here.
For example:
(<plugin> stands for the unique name of a plugin)
/<plugin>/addport <name>
/<plugin>/port/<name>/range 0 10
/<plugin>/port/<name>/default 5
/<plugin>/port/<name>/unit octaves
This is a trivial example of course, for a real format we'll have to
think about grouping, port types, etc.
The underlying idea here is that a command language can be used for
configuration as well, and that the _description_ of a plugin is in fact
used to _configure_ its host in order for it to be able to host the plugin.
Now if a host has already the code to accept OSC commands for plugins,
why not use a simple extension of the same code for initialisation as
well?
For example, AMS allows the user to redefine the range of a control
port. Imagine an implementation where the audio part and the GUI are
separete processes, talking to each other via OSC. The same message
that is used to dynamically redefine a slider range can be used to
set its initial range, so it would be natural to already have it
in that format in the plugin description.
Maybe I'm just dreaming...
--
Fons
On Fri, May 14, 2004 at 12:01:01PM -0400, Paul
Davis wrote:
??? Not if the data format is specified. I will fiercely resist any
standard that is defined as a library interface.
Me too, I'd like generic metadata handlign engines to be bale to process
the plugin descriptions (eg. for documentation servers and whatnot). I
don't mind *IFF* the metadata file has a simple, human readable
syntax (no XML please) that can be parsed line by line.
no XML, and yes, parsable line by line, and yes, human readable. *but*
the plan should be to use the supplied library to get and set
values. nobody should be doing it themselves otherwise we end up with
an almighty mess.