[gmpi] Re: on mutliple sample types (OT, but let's finish?)

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 16 Dec 2003 14:59:47 -0800

On Tue, Dec 16, 2003 at 02:36:59PM -0800, Chris Grigg wrote:
> >I like the sub-graph plugin because it does the absolute minimum number of
> >conversions necessary - only at the edges of the clump.  The clump of
> >plugins may be 1 or 100, but as long as they are clumped together, there is
> >no need to convert float to int back to float to int to float...
> 
> Do you mean a) that the sub-graph plug-in is a GMPI host, or b) that 
> it's a vendor-supplied, vendor-native, vendor-specific thing?  Well, 

It's a GMPI plugin which hosts DSP-accelerated plugin(s).  The GMPI host
(the user app) passes buffers to the GMPI plugin.  The GMPI plugin converts
the data to the DSP accelerated data type, then runs all the contained
plugins.  When they are all done (it could be 1 or more plugins) the GMPI
plugin converts back to the GMPI native type (float?) and the GMPI host
continues.  Follow?  That could be done for each accelerated plugin, and
that is the easiest way to imagine it, but the sub-graph is a nice
optimization, I think.

> either way there might be issues with driving sub-plug parameters 
> (among other things) since most sequencers are set up to feed 
> automation parameters, etc. from specific tracks to specific plugs, 

The GMPI plugin can expose GMPI parameters that happen to match the
parameters of the contained plugins.  We've already tentatively agreed that
GMPI needs to support some sort of dynamic parameter lists, right?

> out of the GMPI framework for the sub-plugs, making them second-class 
> citizens... is that what we really want?

Not second class - just non-native.  Well, ok, maybe second class is right.
Everything non-native is second class in a GMPI host.

> Seems like either we need to be confident that our event & parameter 
> automation routing architecture is robust enough -- and interfaces 

I'm confident that we can get it right.

> sub-plugs to receive everything they need through the bottleneck of a 
> master 'sub-graph plug', or else we need to support sub-graphs as a 
> proper host-level feature.  Or else not claim to support DSP 
> accelerators efficiently.

Efficiency IS a concern.  How does a native VST host run Powercore plugins
now?  My understanding was it does almost exactly this same thing, but on a
single-plugin at a time.

Supporting differntly-typed sub-graphs is another way of thinking of what I
proposed as GMPI-provided converter routines.  You convert at the edges of a
clump.  I don't know if we want or need to support sub-graphs any further
(such as load/store - I think that is a host issue).

> Are we -sure- it can be solved given the other constraints we've 
> chosen to date?  Maybe it can, but I'm not at all sure.  How do you 

What's bothering you about it?  I am pretty confident that it should be
relatively elegant to solve.

> see parameters for many plugs being assigned to a sub-graph plug, 
> flowing into and through the sub-graph plug, and fanning out to the 
> contained plugs?  I.e. with the plan we have so far.  Do we need to 
> re-evaluate the control scheme to enable that?

The way I see it is that the sub-graph plug would make it's parameter list
reflect the parameter list of the internal plugins.  To make life easier,
there needs to be parameter grouping or hierarchy, but I think we want that
anyway.

Can you further expound on your concerns?


----------------------------------------------------------------------
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:

  1. Home
  2. gmpi
  3. Archive
  4. 12-2003