[gmpi] Re: My plugin system

So from a reading of your suggestion, in order for a host to support GMPI it must support all possible plugin standards? Does this really get us anywhere from where we are now, which is that any host *could* support all plugin standards but none do? I can see how this might appeal to plugin writers, but us host writers would simply end up having to choose a subset of GMPI plugin types, which is the same as we currently do when choosing between different plugins API's to support.
Please correct me if I have drawn the wrong conclusion from your suggestion.

Mike

Juhana Sadeharju wrote: 
Hello. I shortly describe the plugin system I have been developing.
I see people have already discussed about this kind of systems, so,
consider this as my "yes" vote.

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.)

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.)

3. GUI elements would be available as the flow graph nodes a la
Eventide/Orville. (But a GUI programmed with the current plugin-style
would be possible.)

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.

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.

Advantages:
 -Plugins can be combined because the flow graph def is a part of the
  standard
 -There is no distinction between simple opcodes and complex plugins
 -New plugins could be coded with a simple text editor using the
  standard opcodes and existing plugins
 -Flow graph editors could save the graphs to the plugin format,
  and then the graphs could instantly become usable in other software
 -Commercial plugin developers could save time by coding the GUI
  with the standard set of GUI nodes, by coding big lines as a flow
  graph, and provide only the secret core as a compiled opcode
 -GUI and the effect would not be necessarily tied together; either one
  could be replaced with new one; it would be possible to write GUIs
  which combine many plugins under one GUI; GUI could be replaced with
  a non-graphical UI

I have an experience on making a reverberator with LADSPA packaging,
and can say that the traditional plugin system is the main drawback in
developing effects. The flow graph system is a must as it is modular
and supports re-use.

It could turn out that hosts have to implement support for many
combinations of instructions, but I don't see a problem in that.
It is like that GMPI would be prepared for extensions via the
instruction extensions. If the GMPI is fixed now, then I suspect
it takes many months before we figure out all necessary features
which should be in GMPI.

Best regards,

Juhana

----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe




--
Mike Berry
Adobe Systems


----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: