One more try: HELP! VSTGUI 3.6 on OSX x64, possible? How?

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

AdmiralQuality wrote:
JonHodgson wrote:
VST_FORCE_DEPRECATED=1
Why the VST deprecations? What does that have to do with x64 and GUI issues?
To be honest when I posted that I was getting confused as to which setting was which!

I can't remember when I set the VST deprecations, or why, it may have been a specific issue or simply aiming for completeness. I also note that there are a couple of references to VST_FORCE_DEPRECATED in VstGui.

Post

JonHodgson wrote:
AdmiralQuality wrote:
JonHodgson wrote:
VST_FORCE_DEPRECATED=1
Why the VST deprecations? What does that have to do with x64 and GUI issues?
To be honest when I posted that I was getting confused as to which setting was which!

I can't remember when I set the VST deprecations, or why, it may have been a specific issue or simply aiming for completeness. I also note that there are a couple of references to VST_FORCE_DEPRECATED in VstGui.
Okay, I'll let you know what I find out. (Still haven't had a chance to get back to it. Shortly, I hope.)

Post

Sorry to interupt, but Jon, didn't you do the imposcar? Does this mean you are working on 64bit imposcar2 for mac?

Post

Echoes in the Attic wrote:Sorry to interupt, but Jon, didn't you do the imposcar? Does this mean you are working on 64bit imposcar2 for mac?
Yes

Post

JonHodgson wrote:
Echoes in the Attic wrote:Sorry to interupt, but Jon, didn't you do the imposcar? Does this mean you are working on 64bit imposcar2 for mac?
Yes
Sweet! And your'e doing it without needing to do a full rewrite of the GUI? That would give me hope for Poly-Ana. How nice to stumble on a thread with the developers of the two synths I miss the most from 32bit land. ;)

Post

HiBrasil, if you did not know yet how AQ is talking on forums, then now you know :)
You should only see the discussion on some forums between him and D.Dambrin, you would then find that he is very calm here :D

Ok, let's switch to main topic....

I did the port to x64 of our VSTizer plugins, based on VST SDK 2.4 and VSTGUI 3.6.

- I tested first my VST plugins without editor (I have an option in my code to deactivate them). They compiled and worked like a charm in 64 bits VST hosts (Reaper being the best: it is incredibly tolerant to plugin faults). No change at all needed in VST 2.4 SDK to have a 64 bits plugin. Just create a project within XCode with 64 bits Intel architecture in project parameters and that's done...

- I just needed to change some details in my code (some int needed to be turned to VstInt32 for the x64 target), but nothing to see with the SDK itself

- when I re-activated my editors in the plugin, I got some errors from VSTGUI 3.6.
A) I got a linker problem with QuickTime framework (do not ask me why...), claiming that there was no x86_64 support in it. I just removed the QuickTime framework from my project, and this problem disappeared

B) I got two compilation errors within aeffguieditor.cpp about pointer casts. I just needed to change aeffguieditor.cpp source code to cast properly the pointers, and... everything compiled properly

As far as I can tell for now (tests are not finished on all targets, since the VSTizer is a new product which will be released in January), the x64 versions of my plugins are working nicely under 64 bits hosts on Mac

I am using XCode 3.2.6 on a 10.6.8 Mac (still need 3.2.6 for 32 bits plugins...)

Post

Hi Everyone,
I have just gone through this process making a Universal 32/64bit for my VST/AU for the MAC. Using VSTSDK 2.4 and VSTGUI 3.6

I use XCode 4.3.2 on OSX 10.7.3

Only a few changes were required for the project to compile for 32 & 64bit.
The main things to check and set are:

In your TARGET set:
---------------------
Architectures: Standard (32/64-bit Intel)
Base SDK: Mac OSX 10.6
Build Active Architecture Only: NO
Supported Platforms: macosx
Valid Architectures: i386 x86_64
Mac OS X Deployment Target: 10.5 (or higher)


In xcode_vst_prefix.h set:
---------------------------
#define MAC_OS_X_VERSION_MIN_REQUIRED 1050
#include <AvailabilityMacros.h>
#include <Carbon/Carbon.h>


In aeffguieditor.cpp you need to force one cast since the definition is
different on 64bit:

void InitMachOLibrary () {
const mach_header* header = (mach_header*)&_mh_bundle_header; //
Recast 64bit def pointer

---------------------------------
And that should allow you to generate a Universal 32/64bit VST.


*NOTE: there are some other problems with VSTGUI 3.6 and 64bit

A) the CFileSelector is not supported in 64bit
Solution - try to reverse code the CNewFileSelector functions for VSTGUI
4.0 - good luck with that!
My Solution was - i built my own CK_FileSelector class which i added into the
VSTGUI SDK. (windows and MAC)

B) Sub-Menu's id's are not properly supported in Cocoa (i.e. not the same as
Windows)
I previously modified the MAC Sub-Menus to operate identically to Windows but it only supported Carbon 32bit. It was a fairly simple change to modify the Cocoa OptionMenu() functions.


If you need help with anything.......let me know :wink:

Cheers!......Chris (CK_Modules)

Post

If you use Apple LLVM compiler in 64bit architectures, you probably get

Undefined symbols for architecture x86_64:

"_OBJC_CLASS_$_NSMutableOrderedSet", referenced from:

objc-class-ref in libarclite_macosx.a(arclite.o)

"_OBJC_CLASS_$_NSOrderedSet", referenced from:

objc-class-ref in libarclite_macosx.a(arclite.o)

"_objc_autoreleasePoolPush", referenced from:

___ARCLite__load in libarclite_macosx.a(arclite.o)

"_objc_retain", referenced from:

___ARCLite__load in libarclite_macosx.a(arclite.o)

(maybe you meant: _objc_retainedObject)


linker errors. To solve this select your target and set

Implicitly Link Objective-C Runtime to No

under Apple LLVM compiler 4.2 - Lanuage.

Post

Alright, I'm back at this now. I'm using XCode 3.6 on OSX 10.6.8. (Please don't tell me to upgrade. I'll bite your head off and go on another rant about Apple and their forced obsolescence. :x)

By getting the latest/greatest VSTGUI 3.6 off of sourceforge ( http://sourceforge.net/projects/vstgui/ ... GUI%203.6/ RC2 2010-04-09) I've been able to compile the "tutorial" sample project as x86_64 without ANY changes and it works fine in both 32 and 64 bit hosts. So that was my first problem right there, I didn't realize there was a newer version of VSTGUI 3.6 available than the one I was using. Now that I see x64 working in VSTGUI 3.6, it's just a matter of so much project wrangling to get our products ported...

So now I'm trying to adapt one of my VST 2.4/VSTGUI 3.6 projects to it. I've made all the project settings the same. I've updated all the VSTGUI source files to 3.6 RC2. But when I try to compile it, I keep getting crazy errors. This may just be my ongoing frustration with getting comfortable in XCode. I really feel like I have a hand tied behind my back compared to Visual Studio. (Most of all I miss being able to roll over macro tokens and see what they contain, as well as #if'ed out code being shown in light grey. As well, I don't trust the Find In Project feature. I know for a fact I've searched for stuff that's in there and it tells me it's not. Grrrr!)

I've tried your suggestions C.Kerry. I'm not sure all of those suggestions for the precompiled header file are needed. (The tutorial example's only contains a reference to vstgui.h and that's all.) Anyway, I've had these same results either way.

The first of the thousands of errors I'm getting are...

"Expected '=',',',';','asm' or '__attribute__' before VSTGUI"

...on every line of vstgui.h that says BEGIN_NAMESPACE_VSTGUI, as well as two more of the same error message complaining about "CControlListener" on line 100 ("class CControlListener") and complaining about "namespace" on line 1668 ("USING_NAMESPACE_VSTGUI").

Is XCode or GCC not seeing linefeeds correctly or something? WTF? This is the vstgui.h file exactly as downloaded from sourceforge. And why does that same file work fine in the tutorial project? Is a macro being re-defined somewhere? (I see no warning.) As far as I can see nothing's wrong with the code, it's obviously complaining about the contents of these macro definitions. (Again, it would be a hell of a lot easier if I could just roll over the macros to see what they represent. Such a masochistic development platform!)

Maybe I'm just exhausted after a long day and it'll come to me in my sleep. Any help would be much appreciated. I'm sure it's just some dumb thing.

Post

Looks like you forgot to link a framework (Cocoa, probably), or there is a mixup somewhere in your code, while you XCode compiles Obj-C thinking it's C or vice-versa.
I can not tell you right now where I saw this kind of problem, but I saw such a huge list of 'asm' errors before, and it was quite simple to solve. I will take a look in my notes, to see if I can find something about that.

Benoit
KissBox

Post

BenKissBox wrote:Looks like you forgot to link a framework (Cocoa, probably), or there is a mixup somewhere in your code, while you XCode compiles Obj-C thinking it's C or vice-versa.
I can not tell you right now where I saw this kind of problem, but I saw such a huge list of 'asm' errors before, and it was quite simple to solve. I will take a look in my notes, to see if I can find something about that.

Benoit
KissBox
Again, all project/target settings and frameworks match the tutorial project that works. At least I think they do.

Post

This sounds like an include issue.

I usually compile only one file that fails (right-click on file in project tree & compile) in those cases to reduce the number of errors and keep the build log cleaner. You didn't mention which files throw errors (you can't compile vstgui.h directly but only some cpp files which include vstgui.h). Do all files that include vstgui.h fail or are there maybe some that work?

Generally, have a look in which order you include vstgui.h and other include files. I don't know VSTGUI, so I can't give any more specific advice. It sound like something not too hard to solve, though.

Post

lkjb wrote:This sounds like an include issue.

I usually compile only one file that fails (right-click on file in project tree & compile) in those cases to reduce the number of errors and keep the build log cleaner. You didn't mention which files throw errors (you can't compile vstgui.h directly but only some cpp files which include vstgui.h).
Yes I did, vstgui.h. It's included in the precompiled header file xcode_vst_prefix.h (that filename could be anything). It's also included by many other files in the project, obviously.

Do all files that include vstgui.h fail or are there maybe some that work?
They all fail, of course. There's 6000 error messages in total. I'm just starting at the top as obviously not much will work if vstgui.h won't compile.

Generally, have a look in which order you include vstgui.h and other include files. I don't know VSTGUI, so I can't give any more specific advice. It sound like something not too hard to solve, though.
I've been a professional C programmer for 23 years and a C++ programmer for 19. I know what causes the usual error messages. (My gut instinct on this one is it's bad or missing line feeds, but that just doesn't add up as the exact same file in the "tutorial" project compiles and runs fine.) If we can stick to advice from those who actually have compiled VSTGUI 3.6 for x64 on XCode or are at least experienced in XCode that'll help optimize the signal to noise here.

It's just some peculiarity of XCode tripping me up again, I'm sure. Some dumb little thing...

Post

Those errors look like ones I have seen when the compiler attempts to compile Objective C files with the C++ compiler etc. What is the target's build setting GCC_INPUT_FILETYPE/"Compile Sources As" set to? Should be "According To File Type"

Post

hibrasil wrote:Those errors look like ones I have seen when the compiler attempts to compile Objective C files with the C++ compiler etc. What is the target's build setting GCC_INPUT_FILETYPE/"Compile Sources As" set to? Should be "According To File Type"
I was thinking the same thing, but yes, that's what both my project and the tutorial project are set to so I already ruled that out.

But let me try forcing C++ and see if I don't get an error until the .mm file... HOLY SHIT, forcing it to C++ fixed it! Was it assuming the .h file is straight C or maybe Obj-C? And why doesn't the tutorial project have this problem? This is exactly the kind of XCode insanity I'm talking about. :shock:

Also, how will I be able to get it to compile when I reach the cocoasupport.mm file?

Thanks for that! Moving right along... (still have 6000 errors to work through :) )

Post Reply

Return to “DSP and Plugin Development”