Anyway for a Juce plugin to detect/get track name/color from host DAW?

As the title says, wondering if there was a way to get the host DAW track id/name/color?

1 Like

With Studio One 2.6 and later it is possible using the Presonus Plug-In Extensions ( However beyond that I’m not aware of any way to get this information unfortunately.

This not possible in a cross-platform and cross-plugin-format way. I looked into this a while a ago and even though the AU API has a property to store the name of the DAW track on which the plugin is inserted, even Logic doesn’t fill this property!

1 Like

This is generally supported in the SDKs for VST3, Audio Unit and AAX but I think it only works in current versions of Cubase/Nuendo, Logic Pro X and Pro Tools. AFAIK, the Studio One implementation is independent from the VST3 SDK implementation.

Only VST3 also supports track ID and color, the other SDKs supply only the name.

1 Like

Yeah I was looking into this first for AAX and came to the same conclusion. Seems to be a major missed opportunity.
Avid says they have this request already

would you mind sharing some googleable keywords for implementing this with AU and AAX? It took me quite some time to find the IInfoListener in the VST3 SDK.

@jules as this appears to be supported in AU, VST3 and AAX, what are the chances we’ll get

virtual void AudioProcessor::channelNameChanged(const String& newName) and
virtual void AudioProcessor::channelColourChanged(const Colour& newColour)

at some point? Would you accept patches?


Sounds reasonable - certainly we always consider any good patches!

Yes please! We have a strong use case for this!

Unfortunately I currently only know how to implement this for VST3. Pointers welcome!

In AAX a trackname change is communicated using AAX_eNotificationEvent_TrackNameChanged, with AU it is done using the property id kAudioUnitProperty_ContextName.
AFAIK, anything else (track id and colour) is only available for VST3/Cubendo. At least it was some time ago.

Thank you, very helpful!

Looks like Logic 10.3.1 doesn’t set kAudioUnitProperty_ContextName :confused:

Can we expect JUCE plugin track info support or should I start looking into this by myself, or @pixelpacker and others: would you mind to share what you have so far?

I just checked and it works in our plugins. The callback is done using void PropertyChanged(). I think the name is written into mContextName but I’m currently on Windows so I can’t have a closer look in the debugger.

Sorry, I did not have found the time yet to look into it. Still interested though.

Alright peeps, I had a little time this evening, so here’s a patch for JUCE 5.0.0 (6475111) that adds

/** This gets called when the track- or context name changes. This is currently only implemented
    for AudioUnits.
virtual void trackNameChanged(const String& newName) {}

to AudioProcessor.

juce_AudioProcessor_trackNameChanged_AU.cpp (2.2 KB)

Note: the attached file is a patch / diff, not a .cpp file - otherwise the forum would not let me attach it.

I had a quick look at AUv3 as well, but I’m admittedly a little lost there.



Thanks Ben!

But looking into the JUCE wrappers, it seems the only way to adapt them is by patching the code. Its not possible to overwrite the wrappers…! What an awkward design. But more: what for are the .cpp include iterations? i.e.:

in JuceLibraryCode/juce_audio_plugin_client_VST3.cpp:

#include "AppConfig.h"
#include <juce_audio_plugin_client/juce_audio_plugin_client_VST3.cpp>

in juce_audio_plugin_client/juce_audio_plugin_client_VST3.cpp:

#include "VST3/juce_VST3_Wrapper.cpp"

… etc. to make it all easier? What is JuceLibraryCode for???

I don’t think that having the plugin format wrappers non-customizable is awkward - Actually, I’m more that happy not having to deal with them too often :slight_smile:

regarding the including:
When the projucer writes the project files, you have the option to copy the modules or to leave them in place (which is what I usually opt for). If you don’t copy the modules cpp files will be created in JuceLibraryCode that include the files of the module itself. You can think of it like symlinks that work on all platforms.



attached is a patch that aims to implement

/** This gets called when the track- or context name changes. This is currently only supported
    by AudioUnits, AAX and VST3.
virtual void trackNameChanged(const String& newName) {}

/** This gets called when the track- or context colour changes. This is currently only supported
    by VST3.
virtual void trackColourChanged(const Colour& colour) {}

I’ve only tested the implementation for AAX and AU (in GarageBand). I currently don’t have a way to test VST3 (does anyone know how to obtain a free developer license for something that support VST3?).

I also had a stab at AUv3, but I’m not sure if this is the right approach. I was getting assertRunningOnAppKitThread() when trying to instantiate the AUv3 in Garageband (even without my changes). So I commented out the relevant parts. Anyone with a deeper understanding of how this stuff is supposed to work is invited to give some insight.

juce_AudioProcessor_trackNameChanged_AU_AAX_VST3_AUv3.cpp (8.3 KB)

I’m putting the patch under the WTFPL. So ROLI is free (and welcomed) to integrate the patch into JUCE and also JUCE 4 users are free to apply the patch as well. I’d appreciate if you would share modifications and bugfixes here though.



REAPER? It is not free, but its developers proved to be very kind and responsive enough to provide a NFR license without many questions asked.

1 Like