[gmpi] Re: Topic 7: Audio packaging
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 23 May 2003 16:55:34 -0700
> I agree with Sebastien, the semantics of multichannel audio formats
are more complicated than the hinting approach alone is able to
account for. We need to find a way for a plug to advertise to the
In all the discussion, I haven't seen a SINGLE thing that well-hinted
mono-streams can't do. If Someone gives me one solid reason, I'll shut up.
I just thing hinted mono streams is a much more elegant, simple, and
flexible basis for an API.
Allow a user to connect an arbitrary multichannel signal from a
source to a destination of like format in a single operation?
Preserve the information that LEFT in a stereo line is not
necessarily the same kind of creature as LEFT FRONT in a 5.1 line?
> host what multichannel formats it supports, directly in terms like
mono, stereo, quad, 5.1, 7.1, 9.1, ambisonic, M/S, etc. While there
could be a role for hinting within each of those worlds, it seems
like matching hint tags is unnecessary -- why not just have
per-format rules, e.g. in 5.1 buffer 0 is LF, 1 is CF, 2 is RF, 3 is
LR, 4 is RR, 5 is Sub? This is efficient and unambiguous.
Matching hints seems FAR easier than barfing if the target doesn't fully
understand my stream.
Sometimes it's important that a tool refuse to do a wrong thing
rather than make a possibly incorrect guess at what it should really
do. Sometimes barfing is the right thing to do. (And barfing is
very easy.)
Suppose for example that I have a 5.1 sampler. It exports 6 mono streams.
I want to do some processing to just the front L and R and some other
processing to front C.
If all the formats are bundled what do I do? I have to add some plugin that
converst 5.1 into 6 streams then add one that converts the L and R into a
stereo stream. now I have a Stereo, a Mono, and 3 other Mono streams. I
can process the stereo and mono. Then I have to add a plugin to convert 6
streams to 5.1. But first I have to decouple the stereo into 2 monos.
When you atomically group channels together, you force something like this
to happen.
If you have a bunch of hinted streams, you can connect the L and R outs to
the L and R ins of the the processor, the C out to the Mono in of some other
processor, and have them meet their other 3 friends at the next 5.1 plugin.
No bizarre channel conversions needed.
Your example, in addition to being IMHO a little on the contrived
side, makes certain unnecessary assumptions about how it would work.
It could work lots of ways, including having the host handle it
automatically by popping up a window when you try to make an un-like
connection, ala:
The Source is 5.1, but the Destination is Mono.
Connect which channel?:
[FL] [C] [FR] [RR] [RL] [Sub] [Cancel]
Or else:
The Source is Stereo, but the Destination is 5.1.
Connect which channels?:
L --> (o) FL (_) C (_) FR (_) RR (_) RL (_) Sub
R --> (_) FL (_) C (o) FR (_) RR (_) RL (_) Sub
[Cancel] [OK]
Or if that puts you off -- which I can't understand why it would --
Y your sampler's 5.1 output to (3) 5.1 passthrough plugs which,
through the miracle of process-in-place, take zero CPU. On #1 turn
off all but RR, LR, and Sub, routed to a 5.1 output. On #2 turn on
only L & R, routed to a stereo output. On #3 turn on only C, routed
to a mono output. Patch your stereo & mono plugs inline. Patch the
three outputs into a 5.1 bundler plug. If the lines preserve the
original channel semantics (remember I said hinting -might- have a
role even in an enumerated scheme) then you don't even need to
configure the bundler, it knows what to do.
Where's the pain? It's the moral equivalent of having to use a Y
cord to get at one channel of a stereo signal.
Even simpler: If you really care about doing this kind of thing very
often, then buy stereo and mono plugs with flexible inputs, i.e. will
accept different multichannel input formats on different 'pins,' and
let you pick which one/two channels out of those actually get
processed.
These are all level-of-abstraction decisions that plug vendors can
make for themselves, but if we dn't provide grouping than there's
noreal possibility of achieving its ease-of usein any other way .
Besides, if any particular host wants to expose the individual lines
in a multichannel bundle, then fine, whatever. Nothing's stopping
that. They can sell it as a competitive advantage for certain
markets.
> Once such an approach is chosen, the advantages of the
multiple-channels-per-pin approach become more apparent. The pin has
a property for its multichannel audio format (again mono, stereo,
quad, 5.1, 7.1, 9.1, ambisonic, M/S, etc.), and truly these are each
Some of these are formats, and some are encodings - they are not the same.
Yeah... but they're still different and not interoperable despite
having the same channel counts. And this is not just a stereo issue,
I bet there are cases in the theatre/home-theatre multichannel world
where different formats have the same number of channels but the
speakers are in different places (think of all the combinatoins of
multiple front speakers, split surround, multiple subwoofs, etc.).
Channel count is not the end of the discussion.
I'd argue that M/S and Lt,Rt etc have no place inside a GMPI graph. The
oare a way to encode N channels M channels. If you need to read an M/S
source, convert it into whatever format you want a N mono channels.
???... so here I am with my M-S DAT tape collection -- sound effects
for film post production, for example -- and it's all digitized in a
huge library on my sound library server -- and I'm prohibited from
using a GMPI plug-in in Peak to convert it to stereo at the width I
need? Or more like, I want to dynamically vary the width in ProTools
based on a time-variant automation parameter, so the M-S file is
what's placed in the session, but GMPI says M-S doesn't belong in the
graph, so I can't do that? Seems like the wrong answer.
> of like formats. Otherwise how is a plug supposed to be able to tell
the difference between a stereo stream, an LtRt stream, and an M-S
stream? They're all two channels, after all, but they're not
> interoperable.
Again, Lt,Rt and M/S are encodings.
This seems like saying that because they're inconvenient to one
particular view of the world, we're going to ignore them. What
happens when some wants to use ProTools to reconstruct some damaged
track from the only surviving LtRt mag? Sorry, GMPI can't help
you...?
I mean, yes, in both my examples the question is one mainly of ease
of use and preventing patching errors for the user. But your
examples are also about ease of use, but in stranger/more
creative/less pro use cases. I have the feeling that people (me
included) who know enough to be interested in doing stranger things
will always be able to figure out how to drill down to the detail
stuff, like picking one line out of a bundle. The more industrial
and consumer-level things get, the more important handholding and
convenience and error prevention become.
Sorry for latency on my replies - been a busy week.
Same here, thanks for staying engaged.
-- 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:
