We helped Google expand the reach of its Eclipsa Audio technology by enabling creators to use spatial audio plugins across multiple leading DAWs. Beyond technical integration, we streamlined distribution and feedback processes, reducing operational overhead and accelerating user adoption. This work empowered content creators to deliver immersive audio experiences faster and more flexibly. This was in continuation of our work on creating audio plugins capable of recording spatialized audio in the Eclipsa Audio format (see the first case study: https://www.a-cx.com/portfolio/mvp-eclipsa-audio-plugin/).

Our client

Google

The challenge

After the alpha release of the Eclipsa Audio plugins for Avid ProTools, our next step was to support additional digital audio workstations (DAWs). Our client was focused on supporting REAPER, a music focused DAW used by both big and small content creators and Adobe Premiere Pro, a video editing tool often used for creating and editing YouTube videos. The supported plugin formats for both these DAWs differed from the format supported by Avid ProTools so we needed to both convert the existing plugin to the supported formats and make any additional changes necessary to make the plugin work in these DAWs.

In addition to supporting the new DAWs, the client also wanted us to improve the plugins release and feedback mechanisms. The client needed a more automated way of releasing the alpha version and gathering feedback as their current process of manually providing the installers and collecting feedback was untenable for a public release.

How we helped

The project had 3 main objectives:

  • Add support for REAPER DAW to the plugins.
  • Add support for Adobe Premiere Pro DAW to the plugins.
  • Create a distribution and feedback mechanism for the plugins for the public release.

We decided to port our AAX plugin to the VST3 plugin format since REAPER and Adobe Premiere Pro support it. We knew JUCE should make this process straightforward since it provides compile options for targeting different plugin formats. In parallel, we planned to work on a better distribution mechanism. We created a website to host the plugins and add manual feedback forms to the website to gather feedback. Once we had a website, we added analytics and our tracker to see which DAWs and plugin versions were used. Finally, we planned to create an internal process to automate installer creation and signing to make release and distribution more efficient.

Adding VST3 Support For Reaper

Our first step was to configure JUCE to build the VST3 plugin and see if it would work with REAPER. While REAPER successfully loaded the plugin several parts of the plugin functionality did not initially work, notably exporting files and routing audio between the plugins was failing. We discovered there are two major differences between AAX and VST3 plugins, how the plugins receive export mode notifications and how the plugins request multichannel buses.

Export mode notifications turned out to be a simple fix for REAPER. While AAX plugins receive a notification that file export is starting or stopping at the start and end of the export process VST3 plugins receive the same information before every audio frame. As we used these notifications to tell when to write audio frames to the IAMF file it was critical we handled them properly. We updated our internal functions to better handle the VST3 case where the notification was being repeatedly sent.

Export calls in AAX and VST3

Multichannel bus requests were a more complex problem. For AAX plugins, ProTools provides a list of buses and the plugin returns which ones it will support. Then when the user selects a bus, if the bus size is supported by the plugin, ProTools offers it as an option to be added to the bus. REAPER functions slightly differently, allowing arbitrary output bus sizes for plugins but restricting the number of input channels to the smallest bus size the plugin advertises support for. We ended up using slightly different logic from the AAX plugin to correctly request both a larger input bus and larger output bus for the plugins. For AAX we needed to explicitly indicate we supported different audio element sizes for passthrough mode. In REAPER, we needed to indicate we supported only the maximum audio element size, allowing REAPER to provide up to or less than that number of channels.

Adding Support for Adobe Premiere Pro

After adding support for REAPER we began testing the new VST3 plugin with Adobe Premiere Pro. While the plugins did initially load, we encountered issues similar to those in REAPER, the file export was failing and we were once again unable to request multichannel buses. In addition to these issues, exported audio was often garbled and the JUCE configuration handlers were occasionally crashing.

Our first step was to try and request multichannel buses from Adobe Premiere Pro to ascertain if this was causing the other issues. While Premiere Pro offers support for up to 32 channel audio buses we found there was no way to access these from within the plugin. Both requesting large channel layouts like ambisonics 5 and requesting an arbitrary number of channels failed to allow the plugin to be added. We eventually concluded that the most channels a plugin could access was 16, as Adobe Premiere Pro allowed us to request an ambisonics 3 bus with 16 channels. We modified the functionality of the plugin to work with arbitrary sized buses to support this much smaller bus size.

Configuring Audio Element Tracks in Adobe Premiere Pro

Exporting files in Adobe Premiere Pro also ran into challenges. While we were now handling the export notifications correctly, Adobe Premiere Pro was reinitializing the plugin as part of its own internal export process. This was then leading to mistiming of the export process and empty exported files. In addition, assertion error crashes in JUCE during the export process were causing audio corruption in the non-IAMF output. We spent a significant amount of time testing and probing exactly how Premiere Pro used the plugin before deciding to perform another port, porting the plugin to the AU format.

The AU format is a macOS specific format we had discussed supporting.Originally we had decided to instead port to VST3 as VST3 support is more widespread. However, for Adobe Premiere Pro we found that AU support was much more stable than VST3. After completing the porting work, we found that the persistent crashes had stopped and we were finally able to export IAMF files.

Automating Installer Creation on macOS

Now supporting 3 different plugin formats on 3 different DAWs, we needed a better way of automating both building the plugins and creating the installers. We were building the plugins using Github runners but the signing and notarization of the installers was being performed manually due to the complexity of managing signing certificates. We also needed to support a physical USB signing key which could not be provided to the cloud based runners.

Remote GitHub Runners on MacOS

To resolve the issue we took advantage of Github’s self-hosted runners to build and sign our plugins. We ran the CI/CD pipeline processes on a local laptop which we configured with the macOS and USB dependent signing keys.

Creating a Better Distribution Mechanism

The last key piece of work was to build a mechanism for distributing the installers and monitoring their usage. We deployed a website using WordPress with both a sign-up mechanism and alpha users list. We decided to use Azure Blob Storage along with Azure Front Door to host our installers and Google Analytics along with HubSpot to track website usage and feedback.

Eclipsa Audio Plugin distribution

Using WordPress greatly simplified the process of creating a signup mechanism and allowed us to compile a list of users to provide updates to throughout the alpha testing process. Once we were ready to release to the public, we used the same list to notify users that the plugin was available. Google Analytics tracking on both the website and integrated into our installer allowed us to monitor which versions of the plugin were being used in order to help our client make decisions about features or bug fixes moving forward.

Deliverables

The deliverable of this project was plugin support for both the REAPER and Adobe Premiere Pro DAWs, as well as a process to build, sign, and publicly distribute the plugins. The final solution consisted of the following components:

  • A VST3 plugin compatible with the REAPER DAW.
  • An AU plugin compatible with the Adobe Premiere Pro DAW
  • Github runners to automatically build release installers
  • A signup and download website for publicly releasing the plugin as well as monitoring plugin uptake and feedback

The client’s team succesfully tested and validated the solution. In addition we were able to make the plugins available for use by the general public.

Future Work

The client was happy with the public release and the ability to quickly gather feedback for iteration. We are now helping the client maintain the public distribution of the plugins while they collect and assess feedback to determine the next steps of the project. Meanwhile, we are moving forward with additional features and documentation to help better support creators using the plugins.

Please contact us for more information about this case study or how we can implement Eclipsa Audio technologies in your business. We encourage you to download Eclipsa Audio Plugins and try them yourself. Start your creative journey and watch this video. This video gives tips on Adobe Premiere Pro file export .

Date

07/2025

Languages

C++

Frameworks

JUCE
Protobuf
ZeroMQ
iamf-tools
OBR

Tools

Visual Studio Code
GitBook
Github
Avid ProTools
REAPER
Adobe Premiere Pro

Environment

macOS

Discuss your project

Great things happen when good people connect. Leave us your details, and we’ll get back to you.

By sending the information in this form, you agree to have your personal data processed according to A-CX’s Privacy policy and Cookie policy to handle the request and respond to it.

Related Case Studies