VST3 HOA Support > 3rd order

Would it be possible to add an option for just N discreet channels? I.e not specify an ambisonic bus? I think this is what most developers of multichannel plugins would appreciate

1 Like

Sometimes it is good to know what the channels are, e.g. you may want to know what the lfe is if only in order to ignore it.

Would IExtendedSpeakerArrangement be equivalent to the VST2 behavior ?

Using VST2 and Juce, we used to declare a number of supported in/out configs, specifying only the number of channels, e.g., {2, 2}, {1, 2}, {6, 2}, {6, 6}…
Then the user could choose his loudspeaker layout directly in the plugin. That worked fine basically.

Would be nice to have a simple interface like this in VST3.

Thanks,

Charles

I second this entirely. Multichannel audio is not limited just to Ambisonics, we have now other competing formats such as Spatial PCM Sampling (SPS, aka Mach1), T-design geometries (T-format), MPEG-H, Dolby Atmos, etc.
Also the maximum number of channels should be unlimited: in Wave Field Synthesis it is common to use systems with 128 or even 192 channels. We have a WFS room here in Parma, Italy, inaugurated in 2008 (12 years ago) equipped with a single computer driving 192 channels. The WFS rendering cannot actually be done with a VST3 plugin, simply because the VST3 format does not allow for such channel number, whilst the host program (Plogue Bidule) has no problem managing the RME MADI interface providing them.
In some of these formats, such as MPEG-H and Dolby Atmos, we get a mixture of “loudspeaker” channels in fixed positions and a potentially large number of “sound objects”, which are mono tracks encoding sound sources moving around.
In some other cases, each of these moving sources is Ambisonics-encoded (perhaps just at first or second order) or SPS-encoded, representing the directivity of the sound source with a number of channels, which can then be moved in space and oriented in space (6DOF rendering).
In conclusion, what would be important is to allow for maximum flexibility, both on channel number and channel labelling.
Sticking to a reduced set of predefined “speaker layouts” is something which brings all us back by 20 years.
So Please Steinberg, remove all these limitations form the VST3 SDK…

1 Like

I’d like to voice my support for the approach Oli and Angelo mentioned. It would make things a lot more flexible and allow a lot more formats to be supported.

I would also like to request N discreet channels

1 Like

I see there’s a vote feature now, might be good if everyone still interested in a discrete channel layout, which is definitively necessary for both spatial audio and general research applications, would press that upvote button :slight_smile:

@Yvan @Arne_Scheffler Please tell us, how we can help to resolve this issue.
I have to admit I am not very familiar with the bare VST SDK, as I’ve always used wrappers likes JUCE. However I am happy to dive deeper into it and contribute to it!

The simplest immediate solution would be to take one currently unused bit, and make it mean “the rest of the word is just number of channels.”

This is essentially ExtSpeakerArrangement from above – but it doesn’t necessarily need any additional interface. Just jam the number of speakers in there, and let the user sort it out.

I voted to bump interest in this. It would be really useful to have discrete channel layouts in VST3. At the very least it would be good to have Ambisonics extended to 7th order/64 channels, which was easily possible with VST2.

I’m the same as @DanielRudrich in that I am not overly familiar with the inner workings of the SDK but if I can help out somehow then I am happy to learn it to try help.

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 :smiley:

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 :slight_smile:

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.

Hello @Yvan, is there any progress on getting this into the next SDK by any chance?

3 Likes

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.