[gmpi] Re: Topic 7.1: Channel Formats / XML, Profiles

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 4 Jun 2003 15:09:12 -0700

[I hope this is not seen as OT, it's meant to address the current conversation quite directly.]

1. XML

Think of SGML v's XML. SGML supported /everything/ whereas XML supports
the bare minimum of functionality. Because SGML was so complex it never
took off. In 5 years XML has got massively wider adoption that SGML did in
20.

XML is the example that proves why parameterization does not kill standardization efforts, but rather reinforces them, and is therefore worth the trouble. In fact, XML is -highly- parameterized, which is its strength, and the key to its ability to adapt tightly and appropriately to many different applications, and that (in addition to human/machine readability) is exactly why it's successful, and why it'll probably be a stable, durable basis for products for many years to come. We could learn from XML.

in XML, the character set is parameterized. It can be UTF-8 or UTF-16 now, and in future it could be anything else; they don't have to decide now. This is isomorphic to GMPI's per-sample encoding format. We could make that float or double now, and in future it could be anything else; we don't have to decide now.

In XML, there is no such thing as a generalized XML parser; XML is only an underlying technology model, not an application, and XML only becomes a usable application when combined with a DTD or schema specifically defining an interchange format. This is isomorphic to the proposed signal-level encodings for GMPI, where the underlying technology model is always the same, but can be used for any signal encoding based on separate definitions.

Note that the character set and the DTDs/schemas are completely orthogonal in XML. So could per-sample format and encoding format be in GMPI.


2. Profiles

So here's an idea: Maybe we should consider adapting XML's DTD/schema idea, as a way of addressing the valid concerns about how to manage the many possible format and capability choices, and also a way of clarifying GMPI's many possible target market segments.

In other words, there could be separate GMPI 'format profiles' for different application areas. This could be similar to the way profiles were supposed to work for MPEG-4 (or how they do work or SP-MIDI). So we start by publishing a GMPI 1.0 API, and a separate range of Profiles. A plug or host would say what GMPI API version and what profile it supports, for example 1.0/Basic, or 1.0/Music Production, or 1.0/DJ, or 1.0/Film Mix, etc.

Example profiles might look like this (defaults marked as "^"):

Generic:

    - Basic profile:
        samples =  { float }
        channels = { N-channel linear }

Production systems:

    - DJ profile:
        samples =  { float }
        channels = { stereo linear }

    - Music Production DAW profile:
        samples =  { float^, double }
        channels = { mono linear^, stereo linear, N-channel linear }

- Film Edit DAW profile:
samples = { float^, double }
channels = { mono linear^, stereo linear, LCRS linear, 5.1 linear, 7.1 linear, N-channel linear }

- Film/TV Mix DAW profile:
samples = { float^, double }
channels = { stereo, LCRS linear, 5.1 linear, 7.1 linear, N-channel linear }

- Dolby Mix DAW profile:
samples = { float^, double }
channels = { LtRt linear, N-channel Dolby A, N-channel Dolby B, N-channel Dolby C, N-channel Dolby SR }

- Audio Mastering DAW profile:
samples = { float^, 24bit, 16bit }
channels = { mono linear, stereo linear^, quad linear, 5.1 linear, 7.1 linear, N-channel linear }

Playback systems:

    - MP3 Player CE profile:
        samples =  { float }
        channels = { stereo linear }

- Home Theatre CE profile:
samples = { float }
channels = { mono linear, stereo linear, LtRt linear, LCRS linear^, 5.1 linear, 7.1 linear }

Maybe something along these lines might help clarify which formats are expected to be supported in any given situation, reducing confusion all around, while also preserving overall long-term GMPI architecture flexibility.

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