vst3sdk
vst3sdk copied to clipboard
steinbergmedia
no suitable loudspeaker layout for higher order Ambisonic or arbitrary input signals
With VST2 being deprecated, a lot of higher order Ambisonics plugin manufacturers struggle with portion to VST3, as there's no suitable loudspeaker layout for higher order Ambisonics, speaking up to 7th order -> 64 channels.
Especially, plug-ins with variable order struggle, as there's no discreteChannel layout anymore, especially as discrete layouts aren't allowed to be the default layout (well at least JUCE states that with an assertion).
Even when forced, plug-ins hosts won't send more than 24 channels of audio (22.2?), as it seems to be the layout with the highest amount of channels. However, that number varies from host to host.
Decoders/renderers to 3d audio loudspeaker arrays also struggle as those arrays don't have to be regular/standard layouts.
It's not solely a problem with Ambisonic plug-ins, as there are other multi-channel plug-ins out there, which support an arbitrary number of input channels (sources) which will be encoded into a different format, e.g. up to 64 sources into a panner. Also these 64 input channels need a layout for arbitrary inputs.
The issue has been already discussed here: https://sdk.steinberg.net/viewtopic.php?f=4&t=549 https://sdk.steinberg.net/viewtopic.php?f=4&t=624
So, please add a configuration for discrete channels, as already proposed by Yvan Grabit in the first linked thread!
Seconded. I too am unable to move to VST3, due to this specific limitation.
I would also like to see this sort of support for 3D audio. The VST3 format isn't well suited to plugins with 64 inputs and outputs.
@ygrabit it's been over one year since the first report https://sdk.steinberg.net/viewtopic.php?f=4&t=549
we really need an option to set discrete channels for plugins which don't follow a specific speaker arrangement. The current way of implicitly encoding the speaker arrangement type in the bitset itself (by using different onsets) is rather hacky. As you've already noted, the speaker arrangement type should really be a seperate field. The VST2SDK already did this; also it didn't impose any channel limit. It really is a shame that the VST3SDK is less flexible in this respect than its predecessor.
Maybe Steinberg could add a ISpeakerArrangement interface which allows for better control over the speaker arrangement?
That being said, VST3 plugins can actually use discrete channels. In the implementation of getBusArrangement you just have to return the number of channels you want (up to 64 channels per bus). I played around with the HostChecker example plugin + REAPER and it would happily show 64 available plugin I/O channels if I return UINT64_MAX (= 64 channels). The only problem is the channel count notification from the host, i.e. the setBusArrangement implementation. It's true that REAPER won't report more than 24 channels - but we can ask them to remove this limit!
@DanielRudrich here's a hack for the meantime: if the DAW gives you more than 16 channels via setBusArrangement, return 64 channels in getBusArrangement and disable automatic ambisonic order selection. This way, automatic ambisonic order doesn't work for 4th/5th order, but at least you can still set the order manually (as all 64 available ambisonics channels will show up). You probably need to hack the JUCE VST3 wrapper. Contact me if you need help (I'm currently working with the VST3SDK).
Apart from that, you could ask Justin from REAPER to do the following:
- when loading a plugin, query for a "discreteChannels" property. If this returns true then pass the actual channel count to
setSpeakerArrangement. - implement a host property "discreteChannels" which the plugin can ask for. If this returns true, we don't need to disable the automatic ambisonics order selection for >= 24 channels because we know we'll always get the actual channel count.
This could be coordinated with the JUCE guys. It's probably quicker than waiting for Steinberg to update their SDK...
I just ran into the same problem. Starting out with the latest JUCE version that doesn't provide the VST2 SDK anymore, making an Ambisonics plugin for orders higher than three becomes pretty troublesome, and downgrading to VST2 comes with it's own set of problems :(
Please fix this issue. I've just started porting my plug-ins to VST3, which is fine for 3rd order Ambisonics, but not being able to just specify input and output channel numbers is a real pain.
@ygrabit I have also left a comment on the developer forum, but I would like to stress its importance as this is becoming more and more problematic.
I noted that Wavelab 11 now has 7o Ambi interleaved file support. Without solving this issue how can we develop plugins to serve this channel scope?
+1 for this. VST2 was much better in this regard!
cheers
Bruce
On Wed, 6 Oct 2021 at 11:43, stefan kazassoglou @.***> wrote:
@ygrabit https://github.com/ygrabit I have also left a comment on the developer forum, but I would like to stress its importance as this is becoming more and more problematic.
I noted that Wavelab 11 now has 7o Ambi interleaved file support. Without solving this issue how can we develop plugins to serve this channel scope?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/steinbergmedia/vst3sdk/issues/28#issuecomment-935948939, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFPHH6FLTJKKOJITLY5C7LUFQR5BANCNFSM4GQTSRLQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
@ygrabit @scheffle may we please ask for a brief update/statement whether or not this issue will be taken care of some place in the future? Depending on that we would know if we should wait or look for an alternative. My latest informal information was "next year" but that was a couple of years ago...
In the meantime, some ambisonic plugin developers, like https://www.ssa-plugins.com/ have started to use multiple output busses to achieve higher channel counts. It is ugly, but it works.
Still, it is a shame that there is no proper solution and the VST3 SDK is a real setback in this respect.
Just want to also voice support for this since it doesn't seem to be moving along. Have been following the issue since the initial thread was created back in 2018. Maybe there will be a solution before the 4 year anniversary rolls around?
This is a big blocker for many audio professionals needing access to spatial audio tools. Which is not just limited to research institutions btw... Spatial audio formats like HOA are only growing in popularity. When can we expect a fix?
Also +1 to the much more extensible and future proof solution of discrete channel layouts, as opposed to the strictly limited set of named standard configurations. Often spatial audio formats are output-independent and can be decoded/rendered to any sort of arbitrary configuration.
Any news about this? It'd be great to be able to support at least up to 7th order Ambisonics natively in VST3 and, especially, arbitrary speaker layouts (like in VST2).
Any news on that topic ? Adding at least kAmbi4thOrderACN and kAmbi5thOrderACN would be a real benefit. Thanks
