[gmpi] Re: Topic 7: Audio packaging

> >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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: