[gmpi] Re: Topic 7.1: Channel Formats

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 4 Jun 2003 10:49:55 -0700

 >>>
OK, its /a/ layer of complexity, the base (and entirly functionally complete
IMHO) level being float *in, *out;
<<<

IMO the base level needs to be float *or* double in/out, interleaved or
non-interleaved.  If we do that much, and we assign some semantics to the
channels and give it an ID for an "encoding", we can be done.  Encoding
needn't mean compressed.

I agree with Ron here, and do not quite understand the vehemence of the resistance representing/parameterizing encodings at the GMPI framework level. Maybe folks are imagining more implementation complexity than is actually needed, whereas in fact we could make it wholly transparent for hosts and plugs that don't want to deal with it, simplifying it to a VST-like level by just declaring float the default buffer-level sample encoding for GMPI 1.0, with access to all other sample encodings (even if only float and double are defined for now) via query/set/get calls. Pin-level signal encodings (the LtRt, Dolby SR, M-S, ambisonic etc. stuff) could work the same way, i.e. just declare vanilla uncompressed linear PCM the default. Plugs and hosts that only care about N-channel linear audio float buffers would never even have to know anything else exists.

Really, that's the level of complexity we're talking about. Pretty simple. We could wait until GMPI 1.1 or later to start defining other sample-level and signal-level encodings. But if we leave this level of parameterization completely out of the base architecture, we risk never being able to get there, thus inherently and unnecessarily stale-dating GMPI as a technology framework. Why put all this effort into a technology if it's only going to self-obsolete in a couple years?

-- Chris

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