[gmpi] Re: My plugin system
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 8 Oct 2003 12:59:00 -0700
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
Other related posts:
