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