Current status of Juce plugin support on Mac with cocoa

Audio Plugins
1

Hi Guys,

Just wanted to give you my test results regarding the current status of Juce (r680) on mac regarding plugin use.

  • AULab 2: Works fine
  • Digital Performer 6.02: Display correctly but don’t receive mouse events
  • Garage Band 3: Works fine
  • Live 7.07:
    • AU: UI not displayed and uses generic AU view (crashes when closing window)
    • VST: Works fine
  • Logic 8.02: freeze the host
  • Cubase 4.5.2: Works fine but display wrong plugin name and offset in the UI covering Cubase plugin header

I wasn’t able to test on Protools 8 so far because as soon as I add PT SDK xconfig, JuceDemoPlugin doesn’t build. errors on obj C code.
(juce_LibrarySource.mm) using PT SDK 7.3(does it require SDK 8.0 ?)

By the way, it can be interresting to add an SDK folder in the audio plugins folder where you will put VST and PT SDK so you won’t need to hack the xcodeproj to remove references to jules own home directory. (for header path and PT xconfig)

2

From what I get from the Live FAQ on their website they don’t support Cocoa GUIs. Wonder how long they can carry on with this…

3

Update:

Logic 8.02: Now works fine
Digital Performer 6.02: now works fine

Other issues are still present however.

4

Have you checked with Garageband 5 ? With the last carbon juce, it is causing a strange lag in mouse clicks with a very high cpu load – basically it is unusable. Quite strange. (garageband 3 is working fine , though)

With the mouse offset bug of PT8, those are the two issues that make me want to try to switch to cocoa as soon as possible

5

A few more hosts tested (juce svn r700):

  • Cubase 5: same offset problem, the plugin window is over the cubase toolbar.
  • Metro 6.4: another offset problem the plugin window is displayed outside the container window (with an offset of approx 100 pixels)
  • Reaper 2.56: the window does not receive mouvemove events (everything else seems to work)
  • VSTLord : the plugin window appears on the top-left corner, vstlord says the plugin “is not compatible with composited windows” and quits.
  • when running auval , I get many messages from _NSAutoReleaseNoPool() concerning NSPathStore2, NSCFString , JuceNSWindow_1_46_2
  • GarageBand 5 : no mousemove events either.
6

Thanks, I need to get some of these hosts and do some testing.

7

Some more testing with Pro Tools 8:

  • I’m getting the mouse offset bug ! quite rarely, but it definitively happens.
  • more annoying: when the plugin window is displayed, it is stealing all keypresses (even menu stuff like Command-Q), nothing reaches protools
  • the juce_malloc call in AudioSampleBuffer(float **, int, int) must absolutely be removed, it is causing major freezes of the whole MacOS UI in protools (like 1sec of complete UI freeze every tens seconds, very impressive that such a big freeze is caused by a small malloc of a few bytes in the Render() callback)
8

All mallocs should be removed from the audio probes in PR or you will have trouble.

Which Protools SDK are you using btw ?
I wasn’t able to have the demo plugin be detected by Protools
Any settings you have modified in the project ?

Thanks,

9

I’m using the PT 7.3 SDK (I guess that switching to version 8 SDK means loosing the compatibility with PT 7.3 and 7.4)

To be honest I did not manage to build the juce demo rtas , I only built my own plugin (I’m not using xcode for the build so I’m not very confortable with it) – I just used my own settings that worked with the old carbon juce. If you are getting error 7400 “not enough resources” it is indeed the resource file that is missing (lost my morning on this one)

10

Similar behaviour verified compiling against PT SDK 8.0…

11

I’ll sort that out…

12

Ok, I’ve checked in a hasty fix for the AudioSampleBuffer now - please let me know if it works!

13

I tried the new fix and I’m getting a constant high CPU usage, instead of the “GUI freezing” spikes. The GUI does not freeze, though, but the plug-in is too much CPU consuming compared to the “Carbon” one

14

well, any idea what’s using the cpu? Is it the audio thread, or the GUI? Obviously the GUI’s completely different now, but the audio thread should be pretty much identical…

15

Just in case, if the juce audio plugin use AsyncUpdater for its parameter update, it mallocs so it could lead to some CPU spike in RTAS.

16

I have just tested juce r702 and I am no more getting UI freezes, so for me that issue is fixed. I compared also CPU usage with the carbon version in Pro Tools, and could not find any significant difference.

17

Correct behaviour confirmed here!
The excess of CPU was somehow due do the fact that the wrappers in the tip include juce_amalgamated.h, while I’m using JUCE as a library within my plug-in project, thus the correct header to include must be juce.h.

Done that, everything’s fine now.

…is there a planned or guessed release date for version 1.47? :roll:

18

?? It shouldn’t make any difference at all - the headers are exactly the same either way. Maybe your project just needed a good clean rebuild?

19

[quote=“jules”]
?? It shouldn’t make any difference at all - the headers are exactly the same either way. Maybe your project just needed a good clean rebuild?[/quote]

Don’t know… if it happens again (hope not), I will try to figure out better what was happening.

What about the release of the next version?

20

Ah release dates…
In the case of juce, picking a point to release it is particularly difficult, as the whole thing is just an ongoing process. Maybe I should just do one now - the tip seems very stable at the moment…