[gmpi] Re: My plugin system
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 13 Oct 2003 10:44:58 -0700
On Mon, Oct 13, 2003 at 08:37:12PM +0300, Juhana Sadeharju wrote:
> >immediately strikes me as something you should do as a mini-modular system.
> >Define a very simple plugin system (you don't need to solve all the problems
> >that GMPI does) and make them all mini-plugins. Then wrap that all in GMPI.
> >Very much how Reaktor, Tassman, VazModular etc. do for VST.
>
> What program would schedule such a mimi-modular system? I don't
> want write such a flow engine/scheduler myself as there are
> already plenty available.
Well, internally it is a directed graph, right? I mean, is there any other
way to do an audio-processor like that? Traversing a directed graph is a
very well understood problem. The simplest implementation is a couple dozen
lines of code.
> Are you saying that Reaktor instruments can be run in VST Tassman and
> in VST VazModular? So, I could write my reverb with Reaktor then
> if everyone is able to use Reaktor instruments.
I meant that if you want a modular reverb, you should build a GMPI plug like
reaktor that loads your reverb-parts. You build up your graph internally
and when you get container->process(), you interate over part->process()es.
> So there *is* a GMPI graphs in the standard afterall. Sorry, I thought
Of course! There has to be the notion of a graph. How else are plugins
connected to each other? Whether the graph code is part of the GMPI SDK, a
separate GMPI-Host SDK or totally host-implemented doesn't matter. You need
to build up the graph and run it.
> Lets repeat how I would write my reverb:
> -I would write a multitap plugin; called as multitap()
> -I would write a late reverberator; called as laterev()
> -I would write a bandsplit filter; called as bandsplit()
That would work. I'm still asserting that these are best left as
mini-plugins that run inside one bigger GMPI plugin, but there should be no
TECHNICAL blockage on this.
> -I would write GMPI graph description for how the complete
> reverb is assembled
Assuming there is some sub-graph preset standard or a GMPI-GMPI sub-graph
wrapper plugin. Otherwise the description of the flow becomes host-specific
- part of the project.
> Then the host would take all the functions and the graph for
> forwarding them to a nearest flow system, e.g., to
> Csound or to Reaktor which would support GMPI.
The host IS the graph processor. As I see it, the host has a few
responsibilities:
* processing the graph
* providing a UI
* managing buffers/memory
* doing things that let plugins work (helper-threads, timers, etc)
As I see it, GMPI is not rigth until most everythign else can be a plugin:
sequencers, automation engines, tempo control, MIDI in/out. I'd even like
to see drivers be plugins, but I'm willing to bend on that :)
Tim
--
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:
