AAX_CHostProcessor support

Just a small update:

  1. This a selected audio region:

  2. This is a selected and separated (cmd+E) audio region:

  3. This is a selected and separated audio regions, non-continuous with it’s side audio regions:

Only at the case 3 my plug-in will receive audio data from the selected audio region. Also, this is not affected by the AAX_eProperty_ContinuousOnly.

Hi,
because this is a really useful thread, I’ll post here a question about your EnhancedAudioSuite mod.
How can I get the current timeline TC position in my analyseBlock()? (Something like the juce::AudioPlayHead::getCurrentPosition()).

Thanks a lot!

Did you ever figure this out?

There’s no transport in CHostAudioProcessor.

AudioSuite is working in a clip resolution or selection. You cannot obtain other data.
The default AAX wraps AudioSuite and supports transport.

You can query if you’re running as AudioSuite with the normal plug-in but, you’ll lack random audio access.

The two are different APIs. each has other features & restrictions.

1 Like

Great stuff! This AudioSuite code should be part of JUCE.
One little note: A readme with requirements (like following the ARA_SDK main branch instead of a release tag) would be great!

I also made a list with the new definitions I could find with short descriptions if you are interested in adding that as documentation (but Id rather not share it here because of the NDA with Avid).

Similar to JUCE, this is “wrapping” the AAX SDK.
The great thing with open-source is the ability to collaborate.

Sound Radix already accepted PRs and made several fixes from other companies using the SR JUCE fork to support AudioSuite/CHostProcessor.

1 Like

How can I get the original cliplength in getOfflineRenderOffset()?
I tried to use getRandomAudioReader() but this will be a nullptr and it seems it’s anyways not initialized before prepareToPlay(), which is called later.
If compiler Optimisation is of endOffset will be equal to the clip length so I used this first, but as soon as any compiler optimisation is on startOffset and endOffset will be uninitialised.
We need the original cliplength to calculate the offset.

In TranslateOutputBounds() I added

                startOffset = iSrcStart;
                endOffset = iSrcEnd;

So now if getOfflineRenderOffset() is called startOffset is 0 and endOffset is equal to the cliplength, this is what I would expect them to be. Correct me if I’m wrong.

Thanks in advance

Hi all,

first of all a big THANK YOU to @ttg , @yairadix and everyone at SoundRadix for sharing your CHostProcessor implementation in JUCE. Very much appreciated!

I came across two issues:

  1. the channel order of AudioChannelSet returned by the audioProcessor doesn’t match the order of the processed clips. For example, if I analyse a 5.1 track, the AudioChannelSet order is
    L, R, C, LFE, Ls, Rs
    although the channel order of the buffer from analyseBlock is
    L, C, R, Ls, Rs, LFE
    Is that intended? I know that Pro Tools use other channel order configs than JUCE and just wanted to be sure that I’m not missing something. I haven’t seen that problem with the AAX API Audio Suite.

  2. when analysing, more samples are read than selected. The bufferSize seems to be fixed to 65536 samples per block and there will always be more blocks analysed than selected. It seems to be one or two block before and one or two blocks after the selected clip. I use create continuous file, multi-channel mode and entire selection. That’s a problem as I need to measure the exact length of the selected clip without any adjacent clips. Is there a way to “truncate” the blocks that are analysed?

Thanks,
Stefan

okay, my bad. The handle length will also impact processing on continuous files and entire selection. Using JucePlugin_EnhancedAudioSuite_DisableHandles did the trick.

BUT the last audio block will still hold 65536 samples, although the selected file length may be shorter and will read the adjacent clips. I could solve this by using getRandomAudioReader()->lengthInSamples and count down the number of samples of the selected clip.
But is that really intended?

Stefan

Looking at the SDK, it seems so, similar to realtime plug-ins, you just get consecutive chunks of samples. You can debug the code and if you see we get different buffer size, feel free to PR a fix, but… from quick glance, it seems the buffer size provided by Pro Tools / AAX host.

1 Like

After 5 years since opening this topic, I’ve started a new project with it. Upon reviewing the sources, I must say “thanks very much” guys, @ttg @yairadix , it’s truly appreciated.

2 Likes

Thank you very much, everyone. It seems I’ve found exactly what I need for my project. I’m attempting to write a simple plugin that saves a selected track region in Pro Tools as a .wav file. I’m using a forked version of the JUCE main branch. As I’m new to audio programming, I’m struggling to figure out the correct usage.

I’m trying to save data to juce::AudioBuffer accumulatedBuffer in the following method:

void analyzeBlock(juce::AudioBuffer& buffer)

Then, I intend to write it to a file when analysisFinished() is called. However, the resulting file is very short.

With processBlock() and releaseResources(), it works, but I end up capturing all the audio, not just the selected region.

Could anyone suggest how I might resolve this issue?

ChatGPT

I also noticed that when I use the JucePlugin_EnhancedAudioSuiteOnly flag, I can’t find my plugin in either Audio Suite or Insert Effects.

I don’t really understand what you wrote, I’d suggest you open a separate topic.
I’m not sure you actually benefit from AudioSuite CHostProcessor workflow.

Anyway,
There are examples of writing to file such as:

Beware of blocking threads. but please open a separate issue for your specific topic.

Thank you Tal. To give a broader context, my project involves non-real-time processing using a web server. Here’s the workflow: I select an audio region from a track, defined by a [start, stop] interval, and then send this segment to a web server for processing. Once processed, I download the modified file and replace the originally selected region in the track with this processed file.

I understand your suggestion that this could be accomplished with basic “record” and “stop” functionalities outside of an AudioSuite context. However, integrating this process within AudioSuite offers a more streamlined approach, which is what I’m aiming for.

One more time thanks for this thread and sorry for my poor English