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

[hibrasil]

I'm feeling in a benevolent mood, so, despite your aggressive attitude, I thought I'd see what the situation is with VSTGUI3.6 and x64/cocoa. It seems like it is possible and is kind-of working.

the following steps should have you compiling a 32/64 bit VSTGUI "tutorial" plugin. I did this in Xcode3.26 on 10.68.

1 - download the VERY latest SVN version of VSTGUI3.6 branch -

http://vstgui.svn.sourceforge.net/viewv ... stgui_360/

2 - extract vst_sdk2_4_rev2.zip to /vstgui360/tutorial/vstsdk2.4

3 - open /vstgui360/tutorial/mac/tutorial.xcodeproj

4 - select "Tutorial 1 vstsdk2.4" Target and "Release" build config and click build

you should now have a 32/64bit binary in /vstgui360/tutorial/mac/build/Release/

5 - to compile "Tutorial 2 vstsdk2.4" you need to add the "Cocoa.framework" to the "Link binary with libraries" build stage.

I tried the binary in a few hosts with varying results:

reaper_64 OK,
Cubase_64 not OK - no gui
Studio1_64 not OK - crash
Live_64beta - crash
32 bit hosts have strange gui dimensions.

So as far as procedure goes (your original question) -

-merge your VSTGUI 3.6 mods with the Latest SVN version of VSTGUI3.6 (do this under version control, so you can see what changed if it goes wrong)
-make sure you have similar settings in your Xcode project to the tutorial example. (Or replace example source code with your source code in the tutorial xcode project)
-make sure you have the necessary files in your project e.g. cocoasupport.*

now if any of your mouse-mods etc were in the Carbon mouse handler code, you'll need to duplicate that functionality in Cocoa/ObjectiveC

ALL THAT BEING SAID - based on the fact that the tutorial project was not working flawlessly, and that Arne is no longer developing v3.6x i think you will have more trouble and work to do trying to use v3.6 for x64 than v4.x

oli

[AdmiralQuality]

I'm feeling in a benevolent mood, so, despite your aggressive attitude, I thought I'd see what the situation is with VSTGUI3.6 and x64/cocoa. It seems like it is possible and is kind-of working.

the following steps should have you compiling a 32/64 bit VSTGUI "tutorial" plugin. I did this in Xcode3.26 on 10.68.

1 - download the VERY latest SVN version of VSTGUI3.6 branch -

http://vstgui.svn.sourceforge.net/viewv ... stgui_360/

2 - extract vst_sdk2_4_rev2.zip to /vstgui360/tutorial/vstsdk2.4

3 - open /vstgui360/tutorial/mac/tutorial.xcodeproj

4 - select "Tutorial 1 vstsdk2.4" Target and "Release" build config and click build

you should now have a 32/64bit binary in /vstgui360/tutorial/mac/build/Release/

5 - to compile "Tutorial 2 vstsdk2.4" you need to add the "Cocoa.framework" to the "Link binary with libraries" build stage.

I tried the binary in a few hosts with varying results:

reaper_64 OK,
Cubase_64 not OK - no gui
Studio1_64 not OK - crash
Live_64beta - crash
32 bit hosts have strange gui dimensions.

So as far as procedure goes (your original question) -

-merge your VSTGUI 3.6 mods with the Latest SVN version of VSTGUI3.6 (do this under version control, so you can see what changed if it goes wrong)
-make sure you have similar settings in your Xcode project to the tutorial example. (Or replace example source code with your source code in the tutorial xcode project)
-make sure you have the necessary files in your project e.g. cocoasupport.*

now if any of your mouse-mods etc were in the Carbon mouse handler code, you'll need to duplicate that functionality in Cocoa/ObjectiveC

ALL THAT BEING SAID - based on the fact that the tutorial project was not working flawlessly, and that Arne is no longer developing v3.6x i think you will have more trouble and work to do trying to use v3.6 for x64 than v4.x

oli

Now THAT'S so much more helpful than just telling me to give up and throw everything away.

Though it's rather discouraging that Steinberg's own example doesn't run in their own host.

And to go back to square one with VSTGUI 4 and have to rebuild my custom controls from scratch is not an appealing thought. But then neither is fixing the 3.6 x64 implementation. But at this point I should probably evaluate both paths.

Thanks hibrasil. Reason I was getting pissy was because I explained my criteria and reasons for it right at the top, so being told to throw away VSTGUI 3.6 wasn't a helpful answer. This, however, may be! (And if it leads me to the answer, I'll keep my promise from the OP and reward you.)

[davidguda]

AQ: keep us updated on your progress with this issue.
Like you I have locked myself in to vstgui 3.6 but all upgrading issues and possible issues for the future is worrying me, I'm even thinking about biting the sour apple and converting to (expensive) JUCE to futureproof me better.

[Urs]

This may come as a stupid question, but is VSTGUI 4 a complete rewrite or is it based on 3.x? If it's based on 3.x, can't one just diff the current state with the original state of the SDK to extract all modifications and then simply copy those modifications whereever 4 x has the same functions?

And also, as one would normally subclass and leave the original SDK untouched, is it so different that one can't reuse derived classes anymore?

Really curious.

[AdmiralQuality]

This may come as a stupid question, but is VSTGUI 4 a complete rewrite or is it based on 3.x? If it's based on 3.x, can't one just diff the current state with the original state of the SDK to extract all modifications and then simply copy those modifications whereever 4 x has the same functions?

And also, as one would normally subclass and leave the original SDK untouched, is it so different that one can't reuse derived classes anymore?

Really curious.

I've actually had to re-sub-class all my custom controls once already, when I upgraded to VSTGUI 3.6 from whatever the previous "official" version was (3.0? 3.2? I forget what it was.)

And I believe VSTGUI 4 is totally different. Almost a complete re-write.

So as none of the classes I subclassed were structured the same, I had to do it all again. That's the LAST time I ever want to do that unless it's to improve functionality. (I could see going there someday for multitouch or some other big paradigm shift.) But doing all that work again, only to get the exact same results we have now, except back to zero testing? No f'in way!

Also, when I first tried VSTGUI 4, the samples either didn't compile or didn't work (I forget exactly now) so I tossed it out. Maybe it's in a better state now. (I like Howard Moon on the VST and VSTGUI mailing lists to struggle with the unworking stuff. When I stop getting 3 emails every day from him, I know it's time to take another look at it. )

Steinberg really have been making half-baked stuff and throwing it out before it's ready for these last few years (really they've been useless since Yamaha bought them). Same way I feel about VST 3.x. 1. Why? And 2. It doesn't even work.

[JonHodgson]

Panic Ye Not Admiral Quality!

Vst Gui 3.6 working just lovely on OSX 64 here.

I can't actually remember doing much to get it to work either, though that's probably because I'd done so much work transitioning to it (from 3.0) and doing other 64 bit related changes outside the GUI that in comparison it doesn't seem major, though there probably were a few gotchas.

First force vst gui deprecations on, fix any issues that brings up.

Then just switch to a 64 bit build and hit compile, should detect a 64 bit build automatically, you will almost certainly hit build issues, but you just tackle them one at a time.

[AdmiralQuality]

Panic Ye Not Admiral Quality!

Vst Gui 3.6 working just lovely on OSX 64 here.

I can't actually remember doing much to get it to work either, though that's probably because I'd done so much work transitioning to it (from 3.0) and doing other 64 bit related changes outside the GUI that in comparison it doesn't seem major, though there probably were a few gotchas.

First force vst gui deprecations on, fix any issues that brings up.

Then just switch to a 64 bit build and hit compile, should detect a 64 bit build automatically, you will almost certainly hit build issues, but you just tackle them one at a time.

That's wonderful news! (Where does the Cocoa come from? Is there Objective C in there already? Or is that another myth that Objective-C is needed to build Cocoa GUIs? Or that you need Cocoa to be x64 compatible? At this point I really don't know what to believe.)

As I recall, I started this process before but was held up because I was still on Leopard. I have a 10.6.8 Snow Leopard system now which I assume is sufficient? With XCode 3.2.6 installed. (I believe that's as high as I can go without upgrading the OS.)

Also curious, what do the VSTGUI deprecations do? (I'm familiar with the ones in VST, but wasn't even aware there were any in VSTGUI 3.6.)

And yes, I went through the 3.0 to 3.6 thing too. It wasn't fun, and part of why, now that it's done and been stable for a few years, the last thing I want to do is toss that codebase.

I have to step away soon but let me give that a quick try and get back to you. BTW, do I have to get the lastest SVN version as hibrasil suggested? Or will the "official" one work? (Drives me crazy, different versions with the same version number.) I've got two or three small changes/fixes in the VSTGUI files. No big deal to re-do them, but I'd rather not go changing anything unless its necessary.

[AdmiralQuality]

First problem, neither my project, nor the drawtest sample (which my project was originally based on) has x64 as an option for architecture.

Sorry, probably a stupid question, but using XCode to me feels like I'm in a carnival funhouse on acid with a broken leg. How do we add architectures?

EDIT: Nevermind, I think I found it. (Though I still think my face is melting.)

[AdmiralQuality]

ENABLE_DEPRECATED_METHODS, got it...

Man, I can't even find that string in XCode. I was about to post that "depre" doesn't occur anywhere in VSTGUI, then I tried searching for it in MS Developer Studio and there it was.

This is what I mean about the broken leg!

OK, set ENABLE_DEPRECATED_METHODS and I'm still getting "'ControlDefSpec' does not name a type". Any ideas?

[JonHodgson]

That's wonderful news! (Where does the Cocoa come from? Is there Objective C in there already? Or is that another myth that Objective-C is needed to build Cocoa GUIs? Or that you need Cocoa to be x64 compatible? At this point I really don't know what to believe.)

cocoasupport.h and cocoasupport.mm

As I recall, I started this process before but was held up because I was still on Leopard. I have a 10.6.8 Snow Leopard system now which I assume is sufficient? With XCode 3.2.6 installed. (I believe that's as high as I can go without upgrading the OS.)

Your setup is what I'm developing on.

Also curious, what do the VSTGUI deprecations do? (I'm familiar with the ones in VST, but wasn't even aware there were any in VSTGUI 3.6.)

I can't recall off the top of my head, but the important thing is that they haven't bothered to port deprecated functions to Cocoa (no surprise there, that's why you deprecate) so things aren't going to build if you're using them

I have to step away soon but let me give that a quick try and get back to you. BTW, do I have to get the lastest SVN version as hibrasil suggested? Or will the "official" one work? (Drives me crazy, different versions with the same version number.) I've got two or three small changes/fixes in the VSTGUI files. No big deal to re-do them, but I'd rather not go changing anything unless its necessary.

I think I took mine from SVN.

[AdmiralQuality]

Ah, maybe I should sync up with the repository first then.

And sorry, I guess I misunderstood. I'm supposed to turn OFF the deprecations? (Which they are by default, right?)

Again, it's so frustrating in XCode. In DevStudio I'd just roll the mouse over the macro and I'd see what it's value is. But nope, can't do that on a Mac, would make things too easy!

Anyway, I'll get it. Half of my issue is just knowing it's possible, so thanks again for verifying that it is! (Especially after a page of other people telling me to do it other ways! )

[JonHodgson]

Ah, maybe I should sync up with the repository first then.

And sorry, I guess I misunderstood. I'm supposed to turn OFF the deprecations? (Which they are by default, right?)

Sorry if I was unclear

VST_FORCE_DEPRECATED=1

I think it gets forced to that in 64 bit anyway, but if you make sure it's that for 32 bit build then you can catch any related issues without having to deal with any 64 bit build issues.

[Karmacomposer]

According to sourceforge, VSTGui was registered in 2003 and is now only downloadable as v4.x

My guess is that VSTGui 3.6 was written in 32 bit and until it has a 64 bit version, you are stuck with 32 bit.

Additional Project Details
Languages
English
Intended Audience
Developers
User Interface
Plugins, Project is a graphics toolkit
Programming Language
C++
Registered
2003-05-22

Of course, this is just a guess. I have been killing myself trying to find a way to code my plugins in a non-c++ / Delphi language.

Mike

[JonHodgson]

Ah, maybe I should sync up with the repository first then.

And sorry, I guess I misunderstood. I'm supposed to turn OFF the deprecations? (Which they are by default, right?)

Sorry if I was unclear

VST_FORCE_DEPRECATED=1

I think it gets forced to that in 64 bit anyway, but if you make sure it's that for 32 bit build then you can catch any related issues without having to deal with any 64 bit build issues.

And looking again, also

VSTGUI_ENABLE_DEPRECATED_METHODS=0

[AdmiralQuality]

Ah, maybe I should sync up with the repository first then.

And sorry, I guess I misunderstood. I'm supposed to turn OFF the deprecations? (Which they are by default, right?)

Sorry if I was unclear

VST_FORCE_DEPRECATED=1

I think it gets forced to that in 64 bit anyway, but if you make sure it's that for 32 bit build then you can catch any related issues without having to deal with any 64 bit build issues.

Somehow I stopped getting emails about this thread. Catching up. (I've been away from it for a couple days anyway. Distractions, hurricanes, etc.)

Why the VST deprecations? What does that have to do with x64 and GUI issues?

And yes, I don't have VSTGUI_ENABLE_DEPRECATED_METHODS defined, and as far as I can tell (though I trust nothing XCode tells me when I search) nothing else defines it. Maybe I should put it into the project anyway just so I can catch the warning if something else tries to define it.

And karmacomposer... NO! (Read what JonHodgon is telling me. Also, last check-in of VSTGUI 3.6 was 2010-04-09

http://sourceforge.net/projects/vstgui/ ... GUI%203.6/ )

I'll get back to you with my progress, or lack thereof. Thanks Jon, appreciate it!