Version 1.45

[jules]

It's taken two months to get this one out of the door, which is pretty slow for me! No surprises in here for those of you who've been using the sourceforge tip, but it's now an "official" version, and here are the changes:

* big new project in the "extras" folder - a basic audio plugin host! Currently it loads VSTs on PC/Mac, and lets you put them together in a filter graph, which it plays. Hosting functionality is very basic at the moment, but I'm laying down a good architecture to hopefully develop into a full cross-platform plugin host.
* audio plugins: The AudioFilterBase and AudioFilterEditor classes have moved into the main juce tree, and been renamed as AudioProcessor and AudioProcessorEditor. This means you can remove these files from your plugin projects, and should search-and-replace any instances of the old names with the new ones.
* audio plugins: the processBlock() call in AudioFilterBase has been simplified in AudioProcessor. It now just takes a single buffer for all input and output channels, and the accumulate parameter has gone. This will mean tweaking your plugin code, but will probably make it much less complicated.
* audio plugins: AudioProcessor requires a few more methods to be implemented by your plugin than AudioFilterBase did: getInputChannelName, getOutputChannelName, isInputChannelStereoPair, isOutputChannelStereoPair, getLatencySamples (which supersedes the old macro for setting the latency). These are all quite simple to add.
* audio plugins: new methods AudioProcessor::beginParameterChangeGesture() and endParameterChangeGesture() let you tell the host when a parameter-change action starts and finishes.
* audio plugins: new method AudioProcessor::updateHostDisplay() to tell the host that something about your plugin has changed and that it should refresh its display.
* new class: FileSearchPathListComponent, for letting the user edit a FileSearchPath.
* new class: FileDragAndDropTarget, which replaces the old method Component::filesDropped. To use it, just make your component inherit from FileDragAndDropTarget, and it'll receive external file drops. This provides more functionality than the old method, allowing you to track the drag enter/exit/movements as well as just reacting to the drop itself.
* added a critical section option to ReferenceCountedArray
* refactored and added features to the Socket class, replacing it with StreamableSocket (basically the same as the original class), and DatagramSocket.
* refactored the OpenGLComponent, adding new classes OpenGLPixelFormat and OpenGLContext
* A component's KeyListeners are now called before its keyPressed method, so if you want to intercept keys and stop them getting sent to the component, you can add a keylistener and comsume the events.
* added an option to choose a Midi output device to the AudioDeviceManager and AudioDeviceSelectorComponent
* updated the included version of libpng

I'd particularly recommend anyone doing plugins to update to this version, as there are some fairly important RTAS and VST fixes in here.

[Rock Hardbuns]

Sweet. I'll port my rompler synth project tomorrow.

Is the VST 2.3 SDK still supported?

[jules]

Is the VST 2.3 SDK still supported?

I've left the code in there, but TBH haven't tested it. Let me know if I've broken anything. (But is there still a reason to use 2.3? 2.4 is pretty similar, and there aren't any hosts that can't load 2.4 plugins, are there?)

[Rock Hardbuns]

Not sure really. There was a discussion on KvR where some people claimed older hosts can't load 2.4, some popular older versions of Logic or Cubase if I recall.

So I figured I'll go with 2.3 for the time being.

[chkn]

Very Cool !

Any chance to implement a getHostName() method into the AudioProcessor?

In certain cases its important to know which host is running the plugin.

[jules]

Very Cool !

Any chance to implement a getHostName() method into the AudioProcessor?

In certain cases its important to know which host is running the plugin.

Sure, I can add one of those.

[Rock Hardbuns]

So, without the accumulate thingy... I assume accumulation is the default mode then? Or should I clear the buffer?

edit: Also, the JUCE_CALLTYPE macro thingamajig has disappeared in the demo. I assume I should do that too?

[jules]

No, you just replace the contents with whatever you want as your output. That's explained in the comments, I think.

Yes, the JUCE_CALLTYPE stuff is redundant now, so you can lose that.

[Rock Hardbuns]

Okiday.

I think VST2.3 support is officially broken.
I get an array of errors regarding undefined kVstSmpteXXfps constants, and I don't think those are in the 2.3 SDK.

Could be wrong though.

[jules]

Ok. I guess it's just a case of defining those constants if it's using 2.3. If you can give me a list of the offenders, I'll add them (I don't have a 2.3 SDK to try it myself any more).

[Rock Hardbuns]

It's in the VST wrapper, the switch statement at line 791. All the kVstSmptexxx constants. That's it.

(I tested it by commenting the switch out and setting the rate and fps variables directly, after which it builds and runs fine. Yay!)

[Rock Hardbuns]

They come from an enumeration in aeffectx.h. They don't look like they are subject to change so I'm going to hard code the values for now.

[jules]

ok, I'll hard-code those in along with the other ones at line 91.

[Rock Hardbuns]

Hm. Hard coding, or copying the enum, doesn't work it seems. Debugger says info.framerate is set to a random looking number.

Come to think of it, does the 2.3 spec even support frame rates?

edit > Apparently it does support frame rates! I don't know why I'm getting a strange number there though.

edit2 >
The number in question is 0xCCCCCC or -858993460. It is consistent across hosts.

edit3 > Hold your horses there sonny! Isn't the switch supposed to be on ti->smpteFrameRate as opposed to info.framerate? I mean, we are filling the info struct based on the ti struct... right?

[kraken]

yeah julian messed up the structs.
anyway it's a no-brainer to fix it...