[gmpi] Re: Topic 7.1: Channel Formats

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 3 Jun 2003 20:13:53 -0700

First, all the following is based on the assumption that an implementation for the encodings/channel problem can be found that would not unduly complicate life for newbies and old-school plug developers who just want to go on pretending that "out[i] = in[i] * gain" is all there is to writing a plug-in.

Having said that...

>The only 'this is bad' in case 3) is that we, the GMPI designers, 
are forced to comprehensively address the question of multichannel
and encoding semantics, and find an appropriate (i.e. not unreasonably
burdensome) expression of that for the API.


which prompts the question: what are these encodings for anyway? i
consider them to be primarily related to financial and commercial
interests, rather than technical concerns.

But we're in the requirements phase, and technical designs should always be driven by the users' application requirements. Review the list archive for use cases where encodings matter -- for multichannel speaker formats, film mixing and mastering and restoration, M-S sound effects libraries, etc. The scope of use for GMPI plug-ins is defined as being broader than just music studio DAWs.


if a GMPI graph was a standalone processor, and it came equipped with
some kind of single-format audio data interconnect (S/PDIF, ADAT,
IEEE1394 etc), and it didn't handle various encodings, do you doubt
that people would still use it? don't you think they would just sigh
that audio manufacturers could not agree on encodings, let alone make
them all open, royalty and license free? don't you think they'd just
get a 2-way converter to run <your-encoding-here> into and out the
box?

They could do that, but it'd be a hassle, and it'd mean that our failure to solve the problem now would prevent GMPI from ever being able to adequately address those applications. Which, save for GMPI-specific omissions, could reasonably be expected to be handled in the future not with hardware but with software in a plug-in system instead of sticking with lame and expensive patchcords-and-boxes approaches.


why are we doing things differently?

Uh, that'd be "To improve things," wouldn't it?

More seriously: What do you mean, differently from pro audio production techniques? Or different from other plug APIs? Part of the reason for doing GMPI is to allow future plug-ins to do useful things that the current plug API's don't support. If the existing ones did everything perfectly, there wouldn't be as much of a need for GMPI (though standardization alone is a critical benefit of the project).


if there are encodings that
discard information, why are they of interest?

You've never worked on a mix stage, have you? 8-) All Dolby Stereo movie mixes -- probably even the print of Star Wars you watched way back when -- use such encodings. That's reality.

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