On Fri, Nov 26, 2010 at 11:39:01AM +1100, e deleflie wrote: > > OTOH, the main consideration for choosing ACN was that these things > > will in most cases be handled by tools and code rather than by humans. > > I have found that the *most* error prone step is hooking up the Jack > channels from my software, into AmbDec. When using hori I have to skip > certain channels here and there, and its confusing as all hell, > because the FuMa names dont really correspond to the N3D names I'm > using.
Which is why I avoid doing this manually more than once. > So I'll retract my comment on not caring about the channel names .. > > I think the most confusing thing is for the channel names to have an > implied order. FuMa implies the order of the alphabet, but this order > is wrong. And ANC implies its numerical order. It would be strange to > have ACN channel 3 in position 2. It is confusing if the implied order is different from the actual one, in those cases where there is an actual order, like when using a general purpose multichannel file format which has no channel names by itself. And how to do this is what you want to define if I understand the purpose of your initiative correctly. As you say, Jack itself does not have a concept of order of ports. If there is any order in what the user sees it is created by tools such as qjackctl (and that's why ambdec's names currently include the degree as first numerical item - it makes qjackctl do the right thing). But Jack is not the final word on audio app connection systems - it lacks other fundamental concepts as well, such as grouping of ports. > So my preference is for the channels to have no clear implied order. > I'll commit to your 0C0, 1C1, 1S1 names if you confirm they are the > names you'll use in ambdec. The current plans for ambdec & friends are for channel names that contain the ACN as the 'authoritative' part, with l,m and the FuMa name purely as 'informational', for human use only. Any tools and code that tries to automate things should only use the ACN. The exact format is still uncertain, current ideas revolve around the form 'l[+-]m' rather than the 'l[CS]m' one. But in any case, the numerical values used will be l,m,|m|, and certainly *not* the l-|m| which you are currently using. So if you are prepared to change things to be more compatible, this is the thing to change. The choice of [+-] or [CS] as the separator is more a matter of cosmetics - a user could easily match those is the numbers are the same. Over the WE I'll try to talk to some 'power users' to find out what they think about this. Ciao, -- FA There are three of them, and Alleline. _______________________________________________ Sursound mailing list [email protected] https://mail.music.vt.edu/mailman/listinfo/sursound
