2010/2/24 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>de>:
hi alex, fons!
On 02/23/2010 02:37 PM, alex stone wrote:
as fons said, jconv does a nice job of it, and i'm using it exclusively
now. i did my first experiments with farina's method, described here:
http://pcfarina.eng.unipr.it/Aurora/B-Format_to_UHJ.htm
it's essentially the same, only that farina provides one IR per
input/output pair, where fons does the same more elegantly with a single
hilbert transform (they do the 90° phase shift indicated by the "j"
coefficient as you find them on farina's page), and a couple of delays.
I'm on the Hilbert as of last night. Makes a challenging job simpler, i'd agree.
> if you want to do just the latter, and you
already have a b-format, it's
> easier to use the vmic plugin which is part of fons' AMB plugins - it
> does the same job, but is simpler to use (no jack patching).
> if you have a b-format and want to produce
stereo, these are the two
> options you have:
> 1. use UHJ to fold it down automatically
(including extra surround
> information that allows the consumer to blow it up to horizontal
> surround again, with a few compromises). but since uhj basically moves
> the rear sound stage to the front, it can sound slightly over-ambient
> (not as extreme as blumlein stereo, though).
> 2. use a virtual stereo mike to pick out a
stereo perspective. it allows
> for more control, is a lot easier to produce, and it's probably the
> safer option if you want your mix to be reliable on consumer gear...
1.) I've had the ambient overdone already, so i understand what you're
saying here.
2.) Virtual stereo mike? I don't understand this bit. Do we have one
in Linux? Or are you referring to a process i have to build up myself?
>> The intent with this is provide
ambisonic positioning, and convolver
>> tail, right up until downsizing to stereo as the last part of the
>> signal chain.
> i would definitely go that way, to be able
to easily provide a b-format
> output.
Sounds like a plan.
> since you are dealing with artificial
sources anyways, why stick to
> first order? do your panning in higher order instead. the use of
> resources is minimal (although it will create an insane amount of jack
> ports, so use -P2048). it won't make any difference to your UHJ, since
> it only ever sees WXY, but it would enable you to produce really crisp
> n.1 or HOA decodes without any extra work.
I don't know enough about higher order yet, but i am proficient in
handling insane amounts of of ports, so that bit isn't overwhelming.
:)
> just one, totally unrelated, but smart(-ass) nonetheless: could you
> please edit your replies to quote only the part you are directly
> referring to? i'm usually very curious about things you have to say on
> the list, but my mouse wheel finger is getting RSI...
> best,
> jörn
Good point, and i'll endeavour to do this in future.
My thanks to you and Fons for the info, and your continued generosity
in sharing.
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org