Access To Underlying Plugin Instances?


#1

To ease the process of integrating a JUCE based plugin host into my existing host app, I’m hoping to find a straightforward way to get access to some of the plugin data managed by a node of an AudioProcessorGraph. Specifically, I’d like to access a ptr to a plugin’s Audio Unit Component instance or VST instance. I know how to get the AudioProcessor instance managed by a node, but from there I seem to be at a dead end.

I need to send custom user data for some specific plugins, and also be able to introspect some plugins’ unique four character id. I assume there is a way to do this with JUCE, but I haven’t stumbled upon it yet.

Many thanks for any advice you may have.


#2

I’m thinking I may be able to safely dynamic_cast an AudioProcessor* to a ptr to VST or AudioUnit AudioPluginInstance if I knew the AudioProcessor instance was actually a plugin instance. Assuring myself of this, however, seems to be a problem. Perhaps I can get away with this if I can track every node created in my AudioProcessorGraph to assure they’re all of the proper types.

Of course, I’d need to edit some JUCE code to expose the AudioUnitPluginInstance and VSTPluginInstance interfaces, currently inside .mm source files. I’d rather not do this, as keeping track of edits to third party code as the third party matures across releases always seems to get out of hand and become a legacy headache.


#3

That’s actually a trickier request than it sounds… I don’t think I can expose those VSTPluginInstance classes to the host, it’d bring far too much baggage along with it.

How about this: I could add a NamedPropertySet to the audioprocessor class, so you can add custom bits of info to it, and we could make the VST and AU classes stick a bunch of things in there - would that be enough to do what you’re trying to do?


#4

After playing with the JUCE code for a while, I see what you mean by it being tricky to expose the plugin instance classes.

If your proposed solution could provide the contents of the PluginDescription class, and some data specific to the plugin type, as well as a ptr to the AEffect*/AudioUnit, then I think that would be a good way to go. I assume there would be an entry with a string for the name of the class from which the contained data originates, and my code would handle things dependent on this entry. Sounds great!


#5

Actually, you don’t need me to add anything in order to get the PluginDescription - like you suggested earlier, it’s totally safe to do a dynamic_cast<AudioPluginInstance*> from an AudioProcessor* - just remember to check for null in case it’s not a plugin.

What extra information do you need? It might just be easier to add an extra field to the PluginDescription if it’s just missing some kind of detail.


#6

Your proposal for extending/enhancing PluginDescription sounds like an even better idea.

For custom interaction with several third party plugins, I need to issue some calls directly to the plugin instances via AudioUnitSetProperty() and dispatcher(), so I’d need a field that I could cast to either AudioUnit or AEffect*, respective of the plugin type described.

For instance, the ‘audioUnit’ member of AudioUnitPluginInstance; and, the ‘effect’ member of VSTPluginInstance.

I think that’s all the additional data I’d need. Anything else I want I can query directly from the AU or VST instance.


#7

Ok, those things aren’t suitable to go in the PlatformDescription, because that class needs to be serialisable and they’re not constants.

But what I’ll do is to add a method to AudioPluginInstance which returns that value, I think that’d be the best way to do it.


#8

Great!

I’ll be waiting by the GIT.


#9

Just checked-in…


#10

I’ve been making use of your addition to AudioPluginInstance, and it has been a big help. Many thanks, Jules. Sorry I didn’t respond sooner with feedback.

Something that would be a useful addition to PluginDescription, would be a String for internalPluginName, which is often different than the file’s name, which seems to be currently used for the ‘name’ field of PluginDescription.

For instance, with a VST example, a field that would contain the internalEffectName result of:

char	internalEffectName[256];
vstEffect->dispatcher( vstEffect, effGetEffectName, 0, 0, internalEffectName, 0.0 );

Audio Units can also use a different internal name. As it’s the internal name that should be presented to the user in lists/popups, having this info in PluginDescription would make sense.


#11

Sounds like a sensible request. But what’s the parameter for an AU’s internal name? Can’t see any obvious way of getting that…


#12

I know I’m doing it somewhere in my current host monstrosity. I’ll try to dig the code out today or tomorrow.


#13

Here’s what I’m using to get an audio unit’s internal name string as a CFStringRef. I assume you’d go direct from the ConstStr255Param to a juce::String.

   CFStringRef auNameRef;
	
	if (auComponent != NULL )
	{
		ComponentDescription desc;
		Handle nameHandle = NewHandle(sizeof(void*));
		OSErr err0r = GetComponentInfo(auComponent, &desc, nameHandle, NULL, NULL);
		if (err0r == noErr)
		{
			if (nameHandle != NULL)
			{
				HLock(nameHandle);
				ConstStr255Param nameString = (ConstStr255Param) (*nameHandle);
				
				if( nameString )
				{
					auNameRef = CFStringCreateWithPascalString ( kCFAllocatorDefault, nameString, kCFStringEncodingMacRoman );
				}
			}
		}
		DisposeHandle(nameHandle);
	}

#14

Is there an equivalent in cocoa? All those carbon functions are deprecated now!


#15

There’s always a way with Cocoa, right? I’ll need to spend some time with the Apple coreaudio/cocoa lists and a stiff drink.