[gmpi] Re: Topic 7: Audio packaging
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 28 May 2003 14:39:59 -0700
> >OK, I was assuming there were no names. I agree that names solve all
>ordering issues.
Hm, I don't think there's been an agreement that there would be
names. All my examples have been based on known buffer
ordering/indexes, and that seems to me like the better way from an
implementation simplicity POV. Remember, by ordering all we mean is
the order of the buffer ptrs as presented to the plug (maybe in an
array), the buffers themselves can each be anywhere in memory.
Saying that a buffer is named is no different from saying that it is in a
specific location. If you can count on the fact that CENTER is buffers[3],
it essentially is named, yes?
What I'm saying is that within a format, the relative position/meaning of
each signal is known. The issue of multiple 5.1 channel ordering is moot.
You don't just get 6 channels, you get 6 channels WITH KNOWN POSITION. Does
that clarify? I think you and I are saying the same thing.
Yes, from what you just wrote I can see we are. Your use of 'named'
threw me -- I thought you meant to allow the buffer ptrs to appear in
any order, and go ask the host for each one's name/hint/tag (yuck).
So no issue.
> currently different channel orders for 5.1, what was the context
(1394 wire, USB wire, IAC, etc.), and if it's only in stream
transport protocols, then couldn't that be adapted to GMPI a single
convention at the GMPI graph boundary? Seems like that'd remove the
need to handle arbitrary ordering within GMPI multichannel audio
connections?
Yes - this is an input/output issue - your file reader or writer or protocol
sender/receiver handles re-ordering from GMPI to something native.
Bill, do you agree?
> I don't have a specific solution to propose, but from a requirements
POV I have to support Bill on this. Encodings are -not- limited to
tricks to fit more channels into less channels, and even when they
are, they come with a boatload of strings attached that need to be
honored, else all hell breaks loose. For example, it doesn't fit the
shape of the problem space to say that a 2-channel LtRt line should
be encoded as four lines, because you can express things in four
lines that can't be represented in LtRt. Or (sorry to keep with the
OK, this is going to seriously impact those plugins that want to do things
cross-format in a BIG way.
Why? As you say below, plug developers only interested in
conventional unencoded routing needn't bother with this at all.
Wouldn't you expect plugs that handle encodings to be relatively rare
and generally specialized-function plugs? So it'd be rare for a
single plug to support multiple encodings, and the burden is borne
only by those specific plugs.
I don't suspect many, if any, plugins will ever
support these encodings. You'll have your LtRt reader and that's it. :)
i surely agree, this is likely to apply more in certain market
segments than others, and as you say below this is not going to be
used by the vast majority of music production DAW or MIDI+Audio
sequencer consumers, but then again the G in GMPI stands for
'Generalized,' and film mix stages, and home theatre consumer
electronics equipment for that matter, do fall within our project
scope. And are important to host companies -- e.g. a large fraction
of the ProTools (& of course Avid) installed base is in the film
audio post editing & mixing industry.
> in-line, the encoding thoroughly fails. I think at a minimum, we
want to give those (perhaps few) hosts that care about these things a
fighting chance to alert the user that they're about to do something
very stooopid that will break the content, and likely be very, very
expensive to fix later.
I guess I don't REALLY care. I'll never use it. The vast majority of
people won't use it. No need. When DolbyLabs writes their LtRt plugin set,
we'll see people use it. :)
But really, isn't it more useful to say:
1) Read LtRt source
2) decode to 4 channels
3) process with ANY plugin(s)
4) encode to LtRt
5) Output LtRt
rather than:
1) Read LtRt source
2) process with LtRt plugin(s)
3) output LtRt
Depends on the market segment, doesn't it? Let the companies decide
for themselves. And as I pointed out, your proposal to always split
LtRt into discrete channels amounts a gaping hole for introducing
undetectable and unrecoverable errors into the signal (at or near "3)
process with ANY plugin(s)"), which for some classes of products
would be serious, serious problems. Sure, ignoring these issues
would simplify our API design job, but I don't see how we could call
a system that doesn't protect against the breaking of encodings "more
useful".
Fair enough if in your applications you don't want or need to deal
with that, but others might, and say they do. Designed right, an
encoding representation scheme wouldn't complicate implementation for
plugs that don't care to use it.
-- 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:
