This would be a really useful feature. Please allow more than 16 channels and greater than HOA order 3. We are building a 5th order spherical microphone array.
1 Like
@Yvan: Wavelab 11 supports 7o ambisonics interleaved files, correct? does this mean this issue is resolved in the VST3 SDK? or is it imminent?
Coming to the news.
3rd order limitation has been here for a while. Since VST2 is deprecated, there is not much possibilities for developers that want to work with VHOA or discreet setups.
Is there ongoing work on this topic at Steinberg ? How about the first proposal by @Yvan in 2020 ?
Thanks
1 Like
Let’s hope CLAP will solve this eventually.
@Yvan @Arne_Scheffler sorry for tagging you directly, but this is still a big issue for all Ambisonic plug-in developers who want to go beyond third order.
Third order is where the Ambisonic format starts to be usable for larger loudspeaker systems and binaural playback. Below that it’s just meh. Steinberg itself provides Ambisonic rendering, even with personalized HRTFs, so this shouldn’t be news.
Next to Ambisonic plug-in developers, there’s also the issue, that feeding larger multi-channel loudspeaker systems isn’t really working as there’s the 24 channel limit, and even worse, no suitable layout for that.
I see that Ambisonics used to be mostly academic and artistic, quite niche. But I would argue that this has changed over the last couple of years.
I don’t ask you to fix that, I actually don’t even know if this is actually possible within the VST3 standard without breaking things, and it should be clear for everyone that breaking interfaces is a big no-go.
The only thing I am asking for sincerely, is that you give us a response which tells us whether or not these issues can be resolved within VST3, and if yes, whether or not Steinberg actually sees this as issues worth to be resolved some day.
With that information, we can either wait and keep on building and testing our plug-ins with VST3, or simply move on, which would be totally fine. No hurt feelings.
So I beg you to give us some kind of clarification.
Sincerely,
Daniel
Hi @DanielRudrich
We had a proposal about having a new interface, but the reactions were not so positive. This will required some works for DAW because it adds a new API…
I was thinking about maybe less breaking changes… one way will be to define for Ambisonics higher orders than 3rd to start from the first bit up to 64 (for 7 order): something like:
const SpeakerArrangement kAmbi4thOrderACN = 0x01FF FFFF; // 0001 1111 1111 1111 1111 1111 1111
const SpeakerArrangement kAmbi5thOrderACN = 0x000F FFFF FFFF;
const SpeakerArrangement kAmbi6thOrderACN = 0x0001 FFFF FFFF FFFF;
const SpeakerArrangement kAmbi7thOrderACN = 0xFFFF FFFF FFFF FFFF;
The advantage is that we keep the same interface and we are compatible with older plugins, the only point is that we can not directly rely on the speaker bit for mapping 2cd or 3rd order to higher order, this has to be done by the host (if needed).
If this is ok we could add it in the next SDK update…
1 Like
Hi @Yvan , thank you for your response!
this looks good to me!
Let me paraphrase the problem and your proposed solution:
SpeakerArrangements are 64bit numbers, each bit representing a Speaker/Channel. With Ambisonics 7th order, 64 speakers/channels would be need, requiring all the available bits → not working as ~34 bits are already occupied by non-Ambisonic speakers.
With your proposal, the SpeakerArrangements beyond third order Ambisonics would kind of break the normal speaker mapping. Would you reinterpret the used speakers in kAmbi4thOrderACN you would get a combination of surround speakers, Lfe2, a mono speaker, first order Ambisonics, and the top side left speaker. As I hope no one ever will propose such a layout it should be sane to use it 
As we are breaking that mapping, would it make sense to mark the arrangements that they are a “special” one? Like setting the 64th bit? Of course no host is checking it right now, but maybe it could help in the future? But I guess this might break retrieving the number of channels by counting set bits. Unless we remove on of the “first” bits? Maybe that’s crazy town, but just want to make sure that when a solution is dropped, it’s the best one currently available 
This will resolve the Ambisonic beyond 3rd order issue, I am wondering if there could be a similar solution for the discrete layouts case, once the speaker mapping has been broken anyways?
We are still fighting with this limitation too. Discrete channels would be ideal for our use case where we are dealing with object-based audio and so our input channels are not any sort of speaker layout or HOA. Ideally we also want to support 128 object inputs (discrete channels) as soon as possible.
for object handlingI will recommend to use sidechaining… 1 sidechain for 1 object.
Hi @Yvan. Is there any update on this? The proposal from your earlier comment would be immediately useful if it made it into the next SDK, even if not a perfect solution to everyone’s requests. HOA is not a niche workflow anymore and there is a real demand for this. We have sound designers unable to author Ambisonics content in their tools of choice because of the current limitations.
As you may very well know, the most recent AAX SDK extended Ambisonics support up to 7th order in Pro Tools, making VST3 strictly the worst option for our end-users right now. So, this is relevant now more than ever.
I’d also like to register my interest in a solution to this issue.
The proposal to use the lowest (N + 1)^2 bits of the SpeakerArrangement to signify an ambisonic layout of order N where N >= 4 is reasonable, and is fairly close to what REAPER already seems to do. I think this would work in practice, although it still limits the number of channels per bus to 64.
The IExtendedSpeakerArrangement proposal also looks alright, although I don’t like the potential for the result of getExtBusArrangement and getBusArrangement to get out-of-sync. It’s not clear how getBusArrangement should be expected to behave in the case that the current bus arrangement can’t be represented as a SpeakerArrangement, for example.
Perhaps this could be made safer by replacing the contents of IExtendedSpeakerArrangement with something like this:
tresult setUsingSpeakerArrangementFormat (int format);
Until the host calls this function, the plugin should assume that the host is old, and is using the current one-bit-per-channel SpeakerArrangement format (format 0). This preserves compatibility with existing hosts. Similarly, if the host is unable to locate this function on a specific plugin, then it knows that the plugin only understands format 0.
After the host calls this function, the plugin knows that any SpeakerArrangements provided by the host may not be strictly one-bit-per-channel. Instead, in format 1, certain bits in the top 32 bits of each speaker arrangement might signal semantics such as “discrete channels” or “ambisonic”. If such bits are set, then the bottom 32 bits of the arrangement can be interpreted as an integer, signifying the channel count or ambisonic order. The host and plugin can still communicate these arrangements through setBusArrangements and getBusArrangement, but using the current format to specify and interpret each layout.
We do not need to add such setUsingSpeakerArrangementFormat, because the plug-in should always provide the previous version setBusArrangement and the new interface (if needed) *IExtendedSpeakerArrangement*, a host supporting *IExtendedSpeakerArrangement* should always check if the plug-in has this new interface at first and then use it, if not then use the previous one.
we will add these new definitions [HOA 4 → 7] in the next update of the SDK coming soon…
3 Likes
My idea was for IExtendedSpeakerArrangement to look like this:
class IExtendedSpeakerArrangement: public FUnknown
{
public:
virtual tresult PLUGIN_API setUsingSpeakerArrangementFormat (int);
static const FUID iid;
};
The host and plugin would still communicate layouts using the existing setBusArrangements and getBusArrangement, but once the host has called setUsingSpeakerArrangementFormat, then both host and plugin know that each 64-bit SpeakerArrangement isn’t necessarily the old one-bit-per-channel format.
I suppose that the implementation would end up functioning in a pretty similar way in either case, but this version would allow for further format updates in the future without adding new interfaces (as long as each arrangement can still be represented by 64 bits).
yes, it could be a solution, we will check more in details this
Thank you for adding support for 7OA. I’m looking forward to working with it!
1 Like