[gmpi] Re: My plugin system
- From: "Michael Gogins" <gogins@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Wed, 8 Oct 2003 21:00:21 -0400
In Csound, an opcode is a virtual base class (though written in C) for nodes
in a DSP graph. Csound has the richest set of nodes of any system I know.
I get the impression that what was being proposed is some sort of automatic
wrapper generator for various classes that might act as nodes in a DSP
graph. The plugin would convey the signatures of these classes to the host,
so that it would know how to fit them into its own graph and dispatch the
calls with the proper types. Presumably the host would already have built-in
wrappers for various plugin types (such as the Csound opcodes, VST plugins,
DXi, and so on).
I think this is an intruiging idea, but it would inevitably incur at least
the overhead of an additional function pointer dereference and call on each
node call, and almost certainly some marshaling overhead. Probably, since
mostly we are dealing with floats and ints in the same address space, that
could be fairly minimal. The power that could be gained would be large.
Juhana, am I understanding this?
It is also the case that if the host could wrap compiled Csound instrument
templates, not just the opcodes, it could obtain from Csound a complete
sub-graph compiled by Csound. This would multiply the power of GMPI
fantastically - it would be a whole DSP language and runtime.
While this is interesting, please note that the concept can be inverted.
That is, the Csound API could be used in place of GMPI or, rather, in place
of all but the host interface to GMPI. People could then define their
plugins either in Csound code, or, since Csound itself supports plugin
opcodes, they could write their plugins in C or C++ as plugin Csound
opcodes. CsoundVST (which I wrote) does this with the VST interface. In
other words, the "upper half" of GMPI would be as we have been discussing,
but the "lower half" would be Csound. Or some other music processing
language.
There is the additional overhead of the Csound (or whatever) runtime, but
the benefit is a gain in power. For those wishing to write plugin code in C
or C++, the plugin interface to Csound (or whatever) might be quite a bit
simpler than what we have been discussing for GMPI.
============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
Silence, a language for programming music and sound
Available at http://sourceforge.net/projects/silencevst/
============================================
----- Original Message -----
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Wednesday, October 08, 2003 3:59 PM
Subject: [gmpi] Re: My plugin system
> On Wed, Oct 08, 2003 at 06:51:52PM +0300, Juhana Sadeharju wrote:
> > 1. Instead of "GMPI gives instructions for how a plugin author should
> > code a plugin", I prefer approach "GMPI gives instructions to host on
> > how a plugin was coded". (Users could utilize existing Csound etc. open
> > source opcodes as plugins without altering code.)
>
> So every host has to support all possible plugin types? With GMPI we are
> making some decisions that TAKE AWAY flexibility from developers. The
goal
> is to have every GMPI plugin work in every GMPI host. By making some
> low-level decisions NOW, we can eliminate the case of PluginA working in
> HostB, but not in HostC.
>
> > 2. I would combine the opcodes and the flow graph description
> > to the same standard. (If we are able to use Csound opcodes "as is",
> > then we sure want build something with them.)
>
> I don't understand what you mean. I'm not very familiar with CSound - how
> does an opcode map to a plugin?
>
> > 4. Plugin package would contain the instructions on how the opcodes
> > were programmed, any number of opcodes, any number of GUI elements,
> > any number of flow graphs, and a master flow graph which ties the
> > given opcodes, GUI elements, and graphs as one plugin processor.
>
> I think you're asking for sub-graphs as distinct entities. There is
nothing
> in GMPI that will prevent this. In fact, it's possible that some code to
do
> that would be part of the SDK, so hosts can load sub-graph presets.
> Alternatively, it should be not-hard to write a GMPI sub-graph plugin,
which
> is itself a GMPI host which can load sub-graphs.
>
> > 5. The standard could have a standard set of graph nodes (opcodes,
> > GUI elements). More opcodes and GUI elements would be available
> > as open source or commercial plugins.
>
> I don't think GMPI is aiming to be as low-level as "Sine Oscillator" and
> "VCA" modules. While it COULD, there are optimizations you can make in
such
> a modular system that GMPI can't make. Is that what you are asking about?
>
> > I have an experience on making a reverberator with LADSPA packaging,
> > and can say that the traditional plugin system is the main drawback in
>
> Can you elaborate? What drawbacks do you find?
>
> > It could turn out that hosts have to implement support for many
> > combinations of instructions, but I don't see a problem in that.
>
> The host writers do. The only reason GMPI might succeed is because it
makes
> hosting easier. Hosts already are faced with supporting a dozen plugin
> formats, and THAT is the reason plugins don't JUST WORK. Then, because
> there are so many different hosts, plugin writers have to write 3 or 4
> versions of their code. And because hosts implement slightly differently,
> the plugins have different workarounds for different hosts. If hosts
start
> supporting GMPI, then (this is the theory part, now) all GMPI plugs should
> JUST WORK. Life is easier for everyone.
>
> To make it work, it needs to be EASY to make your host support GMPI, and
> there needs to be a reason to do it. That's our job. Make the host easy
> to implement, easy to implement FULLY, and easy to implement CORRECTLY.
> Make the plugins easy to implement. Then make some plugins. Free ones
and
> shareware ones at first.
>
> If we do what we hope to do, and we get a little momentum, we'll be
> unstoppable.
>
> --
> Notice that as computers are becoming easier and easier to use,
> suddenly there's a big market for "Dummies" books. Cause and effect,
> or merely an ironic juxtaposition of unrelated facts?
>
>
> ----------------------------------------------------------------------
> Generalized Music Plugin Interface (GMPI) public discussion list
> Participation in this list is contingent upon your abiding by the
> following rules: Please stay on topic. You are responsible for your own
> words. Please respect your fellow subscribers. Please do not
> redistribute anyone else's words without their permission.
>
> Archive: //www.freelists.org/archives/gmpi
> Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
>
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
