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

[AdmiralQuality]

Right now I'm just trying to figure out why VSTGUI_ENABLE_DEPRECATED_METHODS seems to be unset even though I'm setting it to 1 in my project settings. (I wish I could just roll over a macro like in Visual Studio and see what it expands to!) Hmmmmm...

I think you can view the GCC command line when building from within Xcode (in the build results window). Any macros you have defined in your project settings should be right there in the GCC command line.

Yes, it was set. I was misinterpreting the error I was getting, it was my syntax. (Odd, I didn't used to get this error before. Maybe I'm compiling with a different GCC version now that's more strict.)

Anyway, moving along through my errors now. I'm going to try to do this with VSTGUI deprecations enabled, despite the above advice. I really don't want to have to re-write those custom controls that took a month in the first place, and have been tested and tweaked over the years to the point that they're working perfectly.

We'll see...

[Ju2999]

Hi,

in my 64bit build with VSTGUI4.01 there is no reaction in the gui if a parameter was changed from outside, the gui will not refresh. This does not happen while using the 32bit build (Carbon?).

Any idea what I did wrong? I use the recent VSTGUI 4.01 SVN, also tried the VSTGUI4 included inthe VSTSDK3.2 and also the download-VSTGUI4. Compiling with Xcode4/OSX10.6.8.

[AdmiralQuality]

Hi,

in my 64bit build with VSTGUI4.01 there is no reaction in the gui if a parameter was changed from outside, the gui will not refresh. This does not happen while using the 32bit build (Carbon?).

Any idea what I did wrong? I use the recent VSTGUI 4.01 SVN, also tried the VSTGUI4 included inthe VSTSDK3.2 and also the download-VSTGUI4. Compiling with Xcode4/OSX10.6.8.

Saw your post on the VSTGUI list Ju. What do you mean by "changed from the outside"? Automation? Any program load?

(And sorry, I'm still in VSTGUI 3.6, so I might not be able to help.)

[timefreezer]

[quote="gnjp"]I went through this a few years back so I grabbed
a clean version of 3.6 and whipped this up for you.

[url=http://www.mellowmuse.com/vstgui3.6_x64.zip]vstgui3.6_x64.zip[/url]

Add the VST2.4 SDK and the XCode tutorial should compile
straight away as a 64bit version. Had to make a couple
of changes (search MYCHANGE).

best
Gary
Mellowmuse Software
www.mellowmuse.com[/quote]

Hi. I just wanted to read your changes. Did you remove the file? Where can I find it?

[AdmiralQuality]

I went through this a few years back so I grabbed
a clean version of 3.6 and whipped this up for you.

vstgui3.6_x64.zip

Add the VST2.4 SDK and the XCode tutorial should compile
straight away as a 64bit version. Had to make a couple
of changes (search MYCHANGE).

best
Gary
Mellowmuse Software
www.mellowmuse.com

Hi. I just wanted to read your changes. Did you remove the file? Where can I find it?

You shouldn't need any special project, just make sure you get VSTGUI 3.6 RC2, which includes a "tutorial" sample which compiles to x64 with no changes needed.

Make sure you get it from here: http://sourceforge.net/projects/vstgui/ ... GUI%203.6/

[gnjp]

Follow the changes outlined by C.Kerry earlier in this thread, they
are the same changes I had to make to get the tutorial to to compile (Xcode 5.0, 10.6sdk):

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

plus
----
Add cvstguitimer.h, cvstguitimer.cpp
Add cfileselector.h, cfileselector.cpp
Add cocoasupport.h, cocoasupport.mm
Add Cocoa framework to target
In targets build settings, set "Implicitly Link Objective-C Runtime Suport" to NO

[AdmiralQuality]

Yeah, sorry, I should have said I'm still using XCode 3.2.6 on OS X 10.6.8 (Snow Leopard).

XCode is at version 5 now? Is it still missing the stuff XCode 4 was? (I suppose so, if you still need to follow those instructions.)

[LemonLime]

Yeah, sorry, I should have said I'm still using XCode 3.2.6 on OS X 10.6.8 (Snow Leopard).

XCode is at version 5 now? Is it still missing the stuff XCode 4 was? (I suppose so, if you still need to follow those instructions.)

Xcode 5 is still in beta, but it will be launching with OS X Mavericks / iOS 7 in the Fall. I haven't tested the beta myself, so I couldn't say how it compares to Xcode 4, but I've heard mostly good things (apart from the obligatory beta bugs).

[AdmiralQuality]

Yeah, sorry, I should have said I'm still using XCode 3.2.6 on OS X 10.6.8 (Snow Leopard).

XCode is at version 5 now? Is it still missing the stuff XCode 4 was? (I suppose so, if you still need to follow those instructions.)

Xcode 5 is still in beta, but it will be launching with OS X Mavericks / iOS 7 in the Fall. I haven't tested the beta myself, so I couldn't say how it compares to Xcode 4, but I've heard mostly good things (apart from the obligatory beta bugs).

Geezuz Cripes, these guys "up"grade OSes more often than... oh I don't know, something funny. (I'm too weary even to make a good joke about this!)

And of course, in classic Apple style, that will obsolete all existing software so everyone will have to buy it again. And/or, new software that people want to use will require an "up"grade to the new OS (which may well require a new machine) and then after doing that, they'll find all their existing software needs updating -- and none of this for free.

Meanwhile, the lastest version of Windows still runs software from 1995 just fine.

Sigh...