Reaper ATK screencast : Encode mono - part II (Advanced)

[lossius]

Focusing on more advanced approaches, most of which are not available yet.

@joslloand suggest the following addition:

One thing that isn't covered is working with the proximity encoder, with a signal chain looking like:

mono in --> (HPF) --> spread --> push --> proximity

Additionally the pseudoInverse encoder is not ported yet, and hence can't be demoed (see ambisonictoolkit/atk-reaper#2).

And finally I have an idea of making a convolution-based reverb encoder based on the series of B-format impulse responses I have from the Mumuth concert hall in Graz. The idea of this plug need to be further considered as well, before it can even start to be realised.

This also points towards a more general approach that can be discussed as well:

mono in -> four related but different mono sound FXs => AtoB encode

Are there any more creative ideas for how mono sources might be brought into B-format?

[joslloand]

@lossius

With the addition of matrix loading, I'm planning to add "large number" spherical sampling matrices. These will be for large numbers of input/output channels. In the long run, we'll be able to use these to work with FOA in an HOA context. (Fun!)

Regarding impulse responses, we've had Integrate Isophonics Room Impulse Response Data Set on the atk-sc3 list for some time.

I have some mixed feeling about this, actually. There are some technical constraints with how SC3 works with large RIRs which means working with RIRs probably can't be completely transparent on the SC3 side.

Re the ATK "kitchen sink" side of things (i.e., make it "excellent"), there are some RIR issues that I have been intending to sort out. My intention has been to process measured RIRs to do the following:

Among other things, we'll want to correct:

• frequency response
• directional response
• early proximity
• late diffusion

Essentially, the idea is to correct the measured RIRs both in terms of the frequency and spatial response. (Fons Andriessen has advocated doing something along these lines.) Also... doing the above means that we can anticipate extrapolating FOA RIRs to HOA(!).

The short answer, then, is that I'm planning a science project approach to preparing robust RIRs—that perform better than the loudspeakers and microphones used to make the measurements. And, these are intended to be available for download via atk-kernels. The Julia code for processing is anticipated to be made available, too.

What does this mean for atk-reaper for the time being...?

I think the best thing, for now, is to probably include a convolver that takes a single input signal and then convolves with an available B-format RIR. The RIR being loaded from a menu—but not included as part of the ATK installation. I.e., the user can be directed to various download sites for available RIRs.

Aside from the above listed corrections, there are some other issues:

• RIRs at all supported SRs
• initial RIR impulse delay

The long-term goal would be to provide a transparent experience for the user where the corrected (actually, modelled!) RIRs are delivered with the installation and all SRs are supported.

I think I'll file an issue...