[gmpi] Re: Reqs 3.8

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Fri, 12 Dec 2003 14:39:24 -0800

 >>>
i continue to believe that on a given platform (for any given definition of
a "platform"), a GMPI graph should contain one data type to represent PCM
data, just one, and only one. the GMPI SDK would include header files that
define this data type for each platform (it would clearly be trivial to add
new ones if a developer needed it):
<<<

Yes, 110% agree.

I like this too, and (maybe obviously by this point) it's orthogonal to the profiles idea.


I mean, a really smart host writer who wants to could probably figure out how to handle multiple sample formats in a given graph, but that should be left for special cases -- the GMPI architectural model shouldn't IMHO be saddled with this.

Though I think Kord may have a point about the specific case of HW DSP accelerators in re. the need to avoid unnecessary float/fixed conversions. Can this be solved architecturally with sub-graphs, each of a specific sample type, doing conversions only at the bridges?


 >>>
the plugins written for a cell phone will never run on an x86 or PPC based
DAW, and vice versa. please, lets stop coming up with a scheme that pretends
that multiple sample types in the same graph is a good idea, because it
doesn't really help anybody out (it confuses users, creates more work for
host developers, and creates a choice for plugin developers which is
frequently a bad idea).
<<<

Yes, 150% agree.

One type per plugin binary, one type per graph.

Philosophical side-comment: I don't think auto-portability of your process() DSP source code is the big reason to do GMPI, because (as you say) that only helps the simpler and/or less-efficient plugs. It's more that if we make all the packaging cruft that surrounds process() consistent for all the platforms, then you don't have to re-learn and re-write all those different versions of all that cruft, leaving you more time and attention to focus on the actual product design (including optimizing the process() innards for each supported platform, if that's what you want to do; otherwise you just save time==money).


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