[gmpi] Re: My plugin system
- From: Juhana Sadeharju <kouhia@xxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 9 Oct 2003 20:38:27 +0300
Hello.
>From: "Michael Gogins" <gogins@xxxxxxxxxxxx>
>
>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.
If I understood the above correctly, then that it is.
Many plugins takes input and output buffer pointers and tells how
many samples to process. The buffers are only memory somewhere. Now,
could GMPI easily describe the various ways how the plugin could tell
where the pointers and variable are, and how the functions are called?
Most of the overhead happens when the plugin is loaded, and
because most of the plugins process N samples at a time,
there may not be severe overhead at all.
It is different thing to run a VST plugin, than to adapt a VST (say)
plugin to GMPI system the above way. The plugin wrap needs to be
rewritten or automatically generated if because we know the VST
standard, but VST programmers don't have to change the internal
programming style completely.
>From: Tim Hockin <thockin@xxxxxxxxxx>
>
>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?
Yes, but the important thing was the plugin re-usability.
A plugin system which would scale from low-level to high-level
is possible, I'm sure. One could always offer a monolithic plugin
opcode if optimization is desired.
>> 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?
I have separate early reflection, late reverb, multitap delay sections.
Currently all have C function wrappings and I may combine the sections
arbitrarily if I write a master C function. Without writing monolithic
code, for changing the reverb structure, either I should touch the C code,
or combine separate plugins with the third party host. There is no
possibility to define a plugin using existing plugins or effect sections.
Flow graph would be a solution if it would be a part of the standard/
public SDK.
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
Other related posts:
