What is KVR Audio? | Submit News | Advertise | Developer Account

Options (Affects News & Product results only):

OS:
Format:
Include:
Quick Search KVR

"Quick Search" KVR Audio's Product Database, News Items, Developer Listings, Forum Topics and videos here. For advanced Product Database searching please use the full product search. For the forum you can use the phpBB forum search.

To utilize the power of Google you can use the integrated Google Site Search.

Products 0

Developers 0

News 0

Forum 0

Videos 0

Search  

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

DSP, Plug-in and Host development discussion.

Moderator: Moderators (Main)

JonHodgson
KVRian
 
773 posts since 1 Apr, 2003

Postby JonHodgson; Thu Nov 01, 2012 2:33 am

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.
AdmiralQuality
KVRAF
 
6310 posts since 10 Oct, 2005, from Toronto, Canada

Postby AdmiralQuality; Thu Nov 01, 2012 10:26 am

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.)
Echoes in the Attic
KVRAF
 
3711 posts since 12 May, 2008

Postby Echoes in the Attic; Tue Nov 06, 2012 9:41 am

Sorry to interupt, but Jon, didn't you do the imposcar? Does this mean you are working on 64bit imposcar2 for mac?
This is a block of text that can be added to posts you make. There is a 255 character limit. Once I have something clever, I will certainly fill it in.
JonHodgson
KVRian
 
773 posts since 1 Apr, 2003

Postby JonHodgson; Tue Nov 06, 2012 4:37 pm

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
Echoes in the Attic
KVRAF
 
3711 posts since 12 May, 2008

Postby Echoes in the Attic; Tue Nov 06, 2012 5:02 pm

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. ;)
This is a block of text that can be added to posts you make. There is a 255 character limit. Once I have something clever, I will certainly fill it in.
BenKissBox
KVRer
 
25 posts since 10 Feb, 2010

Postby BenKissBox; Sat Dec 15, 2012 11:06 pm

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...)
C.Kerry
KVRist
 
155 posts since 2 Apr, 2005

Postby C.Kerry; Thu Feb 07, 2013 3:38 am

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)
volkanozyilmaz
KVRist
 
34 posts since 16 Oct, 2004, from Istanbul / Turkey

Postby volkanozyilmaz; Sun Feb 10, 2013 11:13 am

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.
AdmiralQuality
KVRAF
 
6310 posts since 10 Oct, 2005, from Toronto, Canada

Postby AdmiralQuality; Tue Feb 19, 2013 3:39 am

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.
BenKissBox
KVRer
 
25 posts since 10 Feb, 2010

Postby BenKissBox; Tue Feb 19, 2013 4:07 am

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
AdmiralQuality
KVRAF
 
6310 posts since 10 Oct, 2005, from Toronto, Canada

Postby AdmiralQuality; Tue Feb 19, 2013 4:11 am

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.
lkjb
KVRist
 
85 posts since 13 Oct, 2012

Postby lkjb; Tue Feb 19, 2013 10:36 am

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.
AdmiralQuality
KVRAF
 
6310 posts since 10 Oct, 2005, from Toronto, Canada

Postby AdmiralQuality; Tue Feb 19, 2013 11:05 am

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...
hibrasil
KVRian
 
587 posts since 23 Jun, 2002, from York, UK

Postby hibrasil; Tue Feb 19, 2013 12:32 pm

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"
AdmiralQuality
KVRAF
 
6310 posts since 10 Oct, 2005, from Toronto, Canada

Postby AdmiralQuality; Tue Feb 19, 2013 12:39 pm

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 :) )
PreviousNext

Moderator: Moderators (Main)

Return to DSP and Plug-in Development