Re: [linux-audio-dev] Re: Plug-in API progress?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ti syys   21 1999 - 21:40:06 EDT


In message <99092200475204.00438_AT_localhost.localdomain>you write:
>On Wed, 22 Sep 1999, Paul Barton-Davis wrote:
>[...]
>> ps. Going slightly off the wall, I think that you handle the GUI element
>> of a plugin API by dynamically compiling the plugin.

>That's useful, but it mustn't under any circumstances be the only way
>to do it , as that rules out proprietary plug-ins. I hardly think it
>will be easier to get the Big Guys to port plug-ins if they have to
>release even the GUI source.

Agreed. And in fact, on reflection, I now think that dynamic
compilation for the GUI side is unnecessary as long as you define some
incredibly basic UI-related objects that the engine can hand over to
the plugin. The most obvious X example would be the connection to the
server. The plugin can then do anything it wants with that connection
(except close it, presumably - hard to enforce, perhaps).

>[...closure based plug-in example...]
>
>I like it. And it kind of fits well together with the fully event based
>instantiation procedure I had in mind... The details of how the plug-in wants
>to keep track of state info etc can be hidden from the engine, which means
>that the public part of a closure (previously: plugin instance struct) can be
>kept very simple without limiting the capabilities of the plug-in API. Have to
>think more about this... But I'll post some more ideas on the event system
>first.

\begin{advertisement}

There are a lot of lessons that I think you can learn from Quasimodo
here, even though that program isn't even finished yet. Last week,
Quasimodo became a shared library. The main() function now looks like
this:

  #include <iostream>
  
  #include "quasimodo.h"
  #include "gtk_ui.h"
  
  main (int argc, char *argv[])
  
  {
          Gtk_UI *gtk_ui;
          Quasimodo *q;
  
          q = new Quasimodo (&argc, argv);
  
          if (!q->ok()) {
                  cerr << "Could not create Quasimodo engine" << endl;
                  return 1;
          }
  
          gtk_ui = new Gtk_UI (&argc, &argv);
          gtk_ui->run ();
  
          return 0;
  }

That is, there is total separation of Quasimodo-the-engine from the
UI. Given that Quasimodo's engine is now capable of scaling to any
number of processors, shares opcodes with the most significant music
programming language around, already runs on Linux and IRIX, and will
soon have both a Python and command line UI (thanks to Stephane
Conversey for these two) to encourage porting to any other platform,
it has a number of reasons to take it seriously.

In writing Quasimodo, I struggled with the same problems of separating
the "guts" of a plugin (called a module in Q) from its visual
interface (if indeed there is one). Its a very difficult problem. On
the one hand, I am a little remorseful that its hard to make Q modules
as attractive as some of the TDM plugins for protools or the VST ones
floating around. On the other hand, the code separation that Q
embodies makes multiple UI's relatively trivial to implement, and, in
the case of the cmdline interface, demonstrates that you don't even
need a *G*UI to make something useful. Someone in the UK wants to use
Quasimodo for something related to blind people producing computer
music - no GUI's there!

\end{advertisement}

I don't know enough about the internals of VST or the TDM plugin
schemes to understand who or what is generating the GUI and responding
to its manipulation, but given that it will be rare for anyone to say
"give me a 250msec stereo delay" - they will more likely say "give me
a delay and let me play with the timing" - defining a control method
for the parameters of each plugin is not a side-issue, its critical.

Just to float an idea: instead of having the GUI run by anything
related to the engine, put the parameters in shared memory (*). Then
the plugin becomes a standalone application which does 2 things. First
of all, it contacts the engine to request insertion of the "guts" of
the plugin. Then it runs a (possibly multithreaded) GUI to allow
manipulation and possibly display of the parameters and other data,
accessed via shared memory. Benno will love this idea, I'm sure :)

You could choose whether or not termination of the GUI would trigger
removal of the "guts" of the plugin.

--p

(*) this is in Quasimodos TODO list, BTW :)


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST