Audio strange towards centre

[iamyila]

Using the binuaral encoder

there is a glitch when going from front and back towards the centre, the sound jumps from muffled to bright.

[mcslee]

Hi @iamyila - if you move the sound extremely close to the center, this is an artifact of what the encoding is simulating. A distance value of 1 implies the smallest normal listening distance. Sounds at a distance of greater than 1 will become quieter as a distance attenuation is simulated.

But, if you move sounds very close to the center, with a distance of less than 1, this simulates the sound essentially entering the listener's head and the energy increases quite a lot. Our encoder does have some rolloff built-in to tame the aggressive levels that can occur, but there will definitely be a change in tone at very short distances.

Is this what you are describing? If not, perhaps could include a screenshot of the panner settings where you are seeing this difference in muffled and bright tones? (e.g. two screenshots, one showing a "muffled" setting and the other showing "bright"). Thanks!

[iamyila]

Hi

If you pass things across the center there is a jump in tone in volume quite dramatic, this doesn't happen with other panners / encoders I use.

Also the two binuraul decoders sound quite radically different, the 3rd order having more problems around the center as I described.

I've made a video so you can see

https://www.dropbox.com/s/4r2so8fxs5hrkhy/e4l.m4v?dl=0

[mcslee]

Thanks - this video is super helpful. I'll take a look at how we might smooth this out. Maybe I can add a bit of clamping to the distance to avoid the value getting too close to 0, or smoothing when at values very near 0.

this doesn't happen with other panners / encoders I use

Any chance you could share which tools work well for you? I might have a look at another tool for reference to see how they are handling this case.

[iamyila]

Cool. Ok that would be great.

I've been using SPAT > Revolution. The ATK toolkit and Wigware panners mostly in reaper.. they are all handling the distance thing a bit differently I think

I've always struggled to get that 'inside the head' sound so a definite increase in energy there is good I think, but if something popped out the back of your head i guess that require some kind of imaginative transition!..

[mcslee]

Yeah, the essential problem with distance = 0 is that most tools use some kind of inverse function to distance to track this increase in energy, but once you get to 0, dividing by zero is obviously undefined. So you do have to decide on some sort of "imaginative" way of handling that poorly-defined case where things suddenly jump from 0 = sound coming from all directions at once completely equally, to a state where there is a well-defined direction to the sound.

[iamyila]

yeh, maybe it never goes to 0, so it's never in your head but hovering around very close, when I say imaginative i don't mean with the code, I mean with the idea of what it sounds like to have something close to your head. I guess if it's in your head then it's a whole new ball game!

Hey i just noticed another issues when I attached an x y controller, the values are very jumpy, this is a smoothing thing I reckon, I added smoothing to my x y to azi dist patch but latency was annoying, plus I couldn't smooth azi because the maths stopped working.

[mcslee]

Smoothing will be a separate issue. Are you using a MIDI controller? Within Max 4 Live, it does not really make sense for us to do parameter smoothing within the patch, as this could potentially interfere with Ableton automation (we could possibly make it an advanced option in the panner device, but that's a new feature and a UI complexity tradeoff there).

If your input device is jumpy, smoothing is probably best added at the input processing level.

[iamyila]

Hey

Yes a midi controller, this time it's two Roli lightpads, before I was using something else. Within my xy to azi distance patch I did put some smoothing in which helped to a point, but was quite latent. I've made a new butchered map8 now so you can smooth the values into the panner and also address the curve shapes and ranges of the controller (something very useful).. there's no option controller side to smooth data as far as I know, was able to do with wii via touchosc

I have found another audio glitch, when you jump to a certain point on the panner, there is a quite loud pop or click, again this isn't something I experienced with the ATK or Wigware panners..

Also could you tell me why the 3rd order binaural decoder sounds like it has a lot of gain added to the signal? Even when it's attenuated to match the normal binaural it seems like it's gained or is it simply because it's summing a lot more channels down to stereo? Doesn't sound quite right to me

[mcslee]

I have found another audio glitch, when you jump to a certain point on the panner, there is a quite loud pop or click, again this isn't something I experienced with the ATK or Wigware panners..

Will have a look at fixing this... it's generally the same smoothing issue, the better place to fix this would be inside the ambiencode~ implementation, but perhaps we can smooth it from above.

Also could you tell me why the 3rd order binaural decoder sounds like it has a lot of gain added to the signal? Even when it's attenuated to match the normal binaural it seems like it's gained or is it simply because it's summing a lot more channels down to stereo?

Yes, this decoder is just summing a lot more orders. The difference in gain is a known issue. I may just reduce the overall gain of this decoder to make it better match the other ones. Thanks for the reminder!

[lossius]

Will have a look at fixing this... it's generally the same smoothing issue, the better place to fix this would be inside the ambiencode~ implementation, but perhaps we can smooth it from above.

Is the interpolation attribute of ambiencode~ active? If so, it is supposed to interpolate from the old encoding matrix to the new over one vector (block). This is the same approach that I use for ATK. Of course the sound of this will also depend on the size of the block. The smaller the vector size, the shorter interval the interpolation takes place over, and it might sound les continuous.

[mcslee]

Is the interpolation attribute of ambiencode~ active?

Just checked and yes - the interpolation setting is already active. So this may just require higher-level smoothing.

[iamyila]

Hello

Was there any development on this? I'm using Envelop for an install now, and I notice a few unwanted clocks when passing the centre of the panner.. have to always avoid 0 position, perhaps a quick workaround for now would be to change the value range on the radius so it never hits the problem area? Could you advise?

Thanks

[mcslee]

Hi @iamyila - this is still on our list and we are looking at some workarounds. What it looks like wewill most likely end up doing is turning off the distance panning in ambiencode~ and implementing our own gain adjustments outside of the encoder, which a smoother algorithm around the very short distances.

I can't promise you when we'll have this work completed.

perhaps a quick workaround for now would be to change the value range on the radius so it never hits the problem area?

That's not a bad idea for a workaround - if you're comfortable making edits with Max 4 Live you should be able to make this change for your own copy. Just un-freeze the device, enable editing, and change the value range on the "Radius" knob so that 0 is not allowed.

[iamyila]

Hello

I got around it because this piece was run by automations to just avoid ever reaching zero and then I smoothed any panning so it wouldn't go too fast, also with azimuth you get a bit of a glitch if you pan too fast across or near the centre

I will try this workaround.

Can I ask another question about decoding? I wanted to make a custom decoder because the set-up I have is in a tunnel, the speakers are in two lines, 4 each side, but I noticed to add a custom decoder there is only angles to change and not distance from the center? I know this isn't proper ambisonics without the circle but I reckon my piece will sound better if I can decode the non-standard array properly.

[ramagottfried]

hi @iamyila -- re: your decoder question, not sure will sound best, it depends on the result you're looking for, and the material you're working with.

one option would be to decoding to 2D, dropping some of the Z axis HOA coefficients -- but it looks like ambidecode only does 3D, if you have Spat that would give you could use that (note that you'll have to rotate the scene 90 deg. to coordinate with Spat).

or you could try remapping the hoa decoder speaker positions from a sphere, and re "encode" them as virtual sources and pan in some other way for the 8 speakers -- there might be some weird phasing but you also might not notice it too much, hard to say. so in this case you would take the decoder 24 outputs, and then use this as 24 sources with vbap or dbap or some other panning method, so your speakers become virtual sources.

another simple approach could be to decode to something like 24 ideal speaker positions in 3D, and then add the signal from the virtual speakers to the real speaker outputs where you want that signal to come from. so for example you could add the speakers on the left side, right side, front back, and make a rough mix that brings the 3D space into the 2D speaker array, basically like a mixer bus summing signal for a given spatial direction.

remember that ambisonics is a "sweet-spot" panning approach, which means that it assumes that the lister is in the center point of the array -- but I've enjoyed HOA arrays from sitting way off-center right next to the speakers on one side of the room before, so my suggestion is to try a few different solutions and see what sounds best in the space with your sound material.

[mcslee]

but I noticed to add a custom decoder there is only angles to change and not distance from the center?

Different distances can be specified. You may have been looking at the examples which use the e4l.ambidecode.angles helper, which assumes that everything is equidistant on a single plane.

But take a look at e4l.decoder.five:
https://github.com/EnvelopSound/EnvelopForLive/blob/master/patchers/decoder/e4l.decoder.five.maxpat

You'll see a message box that sends the configuration metadata to the ambidecode~ object. There are four arguments in each message:
aed 1 45 0 1, aed 2 135 0 1, aed 3 -135 0 1, aed 4 -45 0 1, aed 5 0 90 1

aed

We are specifying "1" for all the distances, you can definitely vary those. You may want to also addesome custom delay-compensation for your speakers that are at significantly different distances. I am not sure that ambidecode~ does any delay compensation based upon different speaker distances.