[gmpi] Re: Topic 7: Audio packaging
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 23 May 2003 14:36:57 -0700 (PDT)
> 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.
> 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.
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.
> 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.
I'd argue that M/S and Lt,Rt etc have no place inside a GMPI graph. They
are 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.
> 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.
Sorry for latency on my replies - been a busy week.
----------------------------------------------------------------------
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:
