Juce VST hacks


#1

I’m just about to spend some time looking at the Juce VST stuff, updating it and bugfixing, because I’ve got a little plugin idea that I want to try out. Might also have a go at doing an AudioUnit wrapper too.

I know a few people have done hacks, bugfixes, etc to the code that’s up there at the moment, but I’ve lost track of who’s done what. So if anyone wants to get their fixes or ideas merged into the next official version, could you give me a shout and remind me what it was that you’ve done? Ta very much!


#2

Here is the highlights of what I did:

  • Didn’t touch anything in audiofilterbase so converting to the new
    wrapper is easy

  • Now you can write multiple plugs using one VST wrapper library since
    I removed the CreateJuceFilter thing and hide all the DllMain stuff
    like I learned from you application class

  • Added a JuceVSTEditor class for consistency and better managed code.
    Also made it possible to use the editor wrapper without the VST
    wrapper in my native VST plugs (but didn’t test it yet this way)

  • Fixed many bugs

  • Formatted the code

  • Improved the way the VST API is used according to tests with many
    hosts. Most important issues where EffEditorClose/Open and the
    SizeWindow since some host don’t do SizeWindow

  • I tested it (with your demo and my plug) on: VSTHost, MiniHost,
    Tracktion, energyXT, Cubase SE 1.06, FLStudio 5, Live 4, Orion, Sonar
    4 and Project 5 (via DXi to VST wrapper). It works well now in all
    hosts

What I didn’t do:

  • Didn’t add new stuff to AudioFilterBase but I know I will need to in
    the future (unless you add them first)
  • Didn’t test on MAC although I put the code where I think it should
    be, except for new code that need to be done for MAC in the sizeWindow
    thing
  • I didn’t test programs, parameters and the chunck function but kept
    it all in the code

Source is here: http://www.achitophelconsulting.com/downloads/MyJuceAudioPlugin.zip


#3

Thanks - I already had your changes. Was there anyone else? I’m sure someone else had done some hacking too…

I’m having fun refactoring all this stuff - should be a nice new version along soonish.


#4

I took ost12666’s code and moved the line: midiEvents.clear(); (juce_VstWrapper.cpp, 526) out of the if (filter->producesMidiOutput()) block.

Also ModulR has his hacked version of juce vst here.


#5

Good stuff. Ta.


#6

okay, after a bit of headscratching i figured out a sensible way of getting setParameterAutomated to work, in a nice JUCEy way without exposing the vst framework to the AudioFilterBase. As you said you’ve not tackled that just yet i thought i’d offer my solution in case it helps at all.

Here’s a rundown on what i’ve done and why:

Changes to AudioFilterBase

  • AudioFilterBase is now a ChangeBroadcaster
  • It now has the following additions…

public:
...

	virtual void setParameterAutomated (int index, float newValue) {};

	int getCurrentActiveParameter()
	{ 
		return currentActiveParameter; 
	}

	void notifyHostOfChange( int paramIndex )
	{
		currentActiveParameter = paramIndex;
		sendChangeMessage( this );
	}

private:

    	int currentActiveParameter;
...

Changes to JuceVSTWrapper

  • JuceVSTWrapper is now a ChangeListener
  • The override of setParameterAutomated has been removed.
public:
...

	// respond to changes in the filter's controls...
	void changeListenerCallback( void *source )
	{
		// find out which parameter has been changed...
		int param = filter->getCurrentActiveParameter();
		float value = filter->getParameter( param );
		// inform the host of the change...
		setParameterAutomated( param, value );
	}
...

Now, let’s presume that the EditorComponent will be using a changeListenerCallback(void*) function to respond to changes in the panel controls. The callback establishes which parameter has changed, and calls owner->setParameterAutomated( param, value );

Here’s an example of what the ‘owner’ filter class’s definition of that function would be:

void ExampleFilter::setParameterAutomated (int index, float newValue)
{
	params[index] = newValue;
	notifyHostOfChange(index);
}

As you can see, it updates the value of the parameter in the filter, and then calls ‘notifyHostOfChange’ with the parameter index.

This causes the ‘currentActiveParameter’ in the audioFilterBase to be set to the current index, and notifies the wrapper of an editor-based parameter change via a change message.

In response, the wrapper asks the filter which parameter it was, gets the value, and then calls the native ‘setParameterAutomated’. This call is for the benefit of the filter (to notify the host), not the host, so it wants to have the original AudioEffect base code to send the appropriate info back to the host. This is why the override was taken out.


#7

Ah, I already sorted out the automation yesterday. I actually opted for something a bit more like the way the VST spec does it, so there are two setParameter methods, one of which also sends a message to the host.

I’ve got the demo plugin all automating nicely now, I just need to clean things up a bit and I’ll get a new release out asap, hopefully tomorrow if I’ve got time.


#8

:slight_smile: that’s good news & i’m sure your code is far more trustworthy than mine! :wink: no sense in waiting around for a solution tho, eh? works a treat anyway.

looking forward to the update


#9