As far as I know, plugins running on Intel Mac have to support compositing window. Especially VSTs on Intel Mac have to check whether the window is compositing or not, and if the given window is compositing, plugin have to make a HIView and embed it to content view or root view. Also have to add
<key>VSTWindowCompositing</key>
<true/>
in the info.plist. We can see the code in vstgui 3.0. and we can check the behavior with VST Lord v0.3. (Universal binary!)
I hadn’t heard about this, but will try to support it.
Does it mean that the plugin isn’t allowed to work directly with a window any more, and can only interact via a HIView? If so, that’s bad news, because it’d mean rewriting all of the Juce windowing code to make it use HIViews…
Please search following mail subject in the VST ML:
“Announcement: Mac VST Editor changes” (April 20th, 2005)
And also read the recent threads “VST on MacIntel”. There is,
[quote]There will be an updated VST SDK we will release which will have support for MacIntel.
One thing I can tell you before we release it, is that a VST plugin now needs to put an HIView into the window the host provides and that the host is allowed to move this view arround. There will be no support for the old mac behaviour. You can test your plugs already with my little VST test host ‘VSTLord’, which only accepts plugins using HIViews, and it also runs natively on any mac with intel processors.[/quote]
and
I’m working hard these days because I have to modify my code (non-JUCE, I wrote it before I met JUCE) to adapt compositing window. We have to support both compositing and non-compositing… it’s hard… At first, checking window attributes, and then branch the code…
VSTGUI 3.0 is a good example for doing that.
Also I think you’ve got a mail from Logic-AU for information about compositing window… similar thing…
jeez… that’s a pain. I think the only solution would be to change all juce windowing to use HIViews, and use a window as a wrapper for normal apps. A total pain to do!
