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

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 16 Dec 2003 17:59:30 -0800

Anyone else, feel free to jump in at any time... ;-)

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.

I follow... but then the plugs in the sub-graph aren't GMPI any more. (Which I guess you allow below.) Don't care for that, seems incomplete.


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

AFAIK that's right, but also unnecessarily inefficient since float/fixed/float conversion, plus 2-way buffer passing across the host/card bus, would have to happen at every single plug boundary.


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).

Yes, we violently agree that conversion is properly done only at clump edges, not at per-plug granularity. The question is, are the plugs inside a non-native clump GMPI plugs, vs. something else? If not, we're done. If so, all of GMPI needs to work at (as somebody pointed out in the last month, and I don't think it was resolved then) at least one level of recursion, and I'm not yet sure we have agreement that it either should, or could as currently envisioned.


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

We -could- just state that this is a requirement, if the group wants that, and be done for now.

Or, to look at it in detail now, we could test it by example... by doing so (see below), I think I now agree with you that this should be doable, providing we can accept some small changes in the way controls/auto parameters/ etc. are identified.


Example

Say I want the following insert plugs (all hypothetical) on a DP audio track, some running native and some running on a PowerCore, in the following order, with all operating as first-class plugs as far as I the user am concerned:

        Slot 1 - Para EQ (native)
        Slot 2 - Waveshaper (PowerCore)
        Slot 3 - Envelope Following Filter (PowerCore)
        Slot 4 - Bit Decimator (native)

Using the subgraph model, for best efficiency the host would have to transform that into the following GMPI graph, i.e. inserting a PowerCore subgraph box around slots 2+3 since they're both PowerCore and converting to float in between would be wasteful:

      Native Graph:
        Native Graph Slot 1 - Para EQ (native)
        Native Graph Slot 2 - PowerCore Graph:  (automatically constructed)
                PowerCore Slot 1 - Waveshaper (PowerCore)
                PowerCore Slot 2 - Envelope Following Filter (PowerCore)
        Native Graph Slot 2 - Bit Decimator (native)

Note the nested hierarchy flavor of this. This might be made to work out pretty nicely if IDs for controls/parameters/automation destination (or whatever we're calling them) were specified in two parts, as a way of achieving the grouping you mentioned: A structure with a plug ID (position in the graph), and a separate ID for the control/parameter/automation destination/whatever. (This would be in addition to the pin/param/control/whatever grouping styles we talked about before, as I don't think the same mechanism would work for both [nor should we try].) Then we could use some kind of path notation for the plug ID part, or maybe it's more like outline numbering in a document:

      Native Graph:
        1 - Para EQ (native)
        2 - PowerCore Graph:
                2.1 - Waveshaper (PowerCore)
                2.2 - Envelope Following Filter (PowerCore)
        3 - Bit Decimator (native)

So the plugs for Para EQ and Env Following Filter could both publish 'Output Volume' parameters, and still be kept distinct ({ 2.1, 'Output Volume' } vs. { 2.2 'Output Volume' ) even though the control paths for both are funnelled through the pins of the PowerCore Graph. So the rule would have to be, any graph would provide a list of all the destinations/targets/etc. it encloses, to any depth, in addition to performing audio sample format conversions on input & output buffers. This way, all the control pins for all the contained plugs are available at the outside of the outermost graph, no matter how deep the subgraphs are, as well as the clump edge audio signal ins & outs. We would also need to make state & preset management target plugs by the same kind of nested ID approach, I think.

So the host app just adds the plugs to the outer GMPI graph in the indicated order, and then all their pins all show up as though they're a simple chain of 4 native plugs; only the GMPI graph manager knows that inside, there's a PowerCore subgraph in there, and that the nested-ID thing is happening. I guess it all comes down to how we handle plug addressing in the GMPI graph manager, seems maybe like it could be made transparent to both the plug and the app. That, and making every GMPI sub-graph a GMPI plug-in.

Anyone see problems?

-- Chris G.

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