[gmpi] Re: My plugin system

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

Other related posts: