Cannot build for MAC

[TonyGlover]

I tried to build the Tale version for mac VST and AU from Iplug example but I have some errors:

Compiling /Users/admin/Documents/WDL-tale/WDL/IPlug/Example/../../lice/lice.cpp
	In file included from /Users/admin/Documents/WDL-tale/WDL/IPlug/Example/../../lice/lice.cpp
		In file included from /Developer/SDKs/MacOSX10.5.sdk/usr/include/math.h
		error: expected unqualified-id before 'double'


In file included from /Users/admin/Documents/WDL-tale/WDL/IPlug/Example/IPlugExample.cpp
	error: cannot allocate an object of abstract type 'IGraphicsMac'

Hardware: PowerPC G5
Software: OS X 10.5.8, XCode 3.1 - I know it's old but theoretically offer maximum of compatibility

[earlevel]

Originally Posted by TonyGlover

Hardware: PowerPC G5
Software: OS X 10.5.8, XCode 3.1 - I know it's old but theoretically offer maximum of compatibility

Tony, in my opinion that's just too old to support—you're not going to find other people making the effort, you'll probably have to do it yourself. Leopard had only limited 64-bit support—the modern world didn't start till 10.6 Snow Leopard. Even that is pushing it.

"OS X 10.5.8, XCode 3.1 - I know it's old but theoretically offer maximum of compatibility"—I'm not sure in what sense you mean this. If you're developing on that, you're going to have trouble supporting recent systems. If you mean that you think you'll be more compatible by developing under an old SDK and assuming backward compatibility of new systems and OS to support it...Apple has never been that much into backward compatibility.

I don't know what "most" companies use these day, but I can tell you that support of 10.8 and later is not uncommon. People running old OS versions typically don't by new plugins, they just keep their old system going, so DAWs usually support further back. Still, I doubt any new DAW version support earlier than the last release of Snow Leopard (DP9: 10.6.8, Cubase Pro 9: 10.11, PT12: 10.8.5, Logic Pro X: 10.11, Studio One 3: 10.8.5, Ableton Live 9: 10.7). If the DAWs don't support it, it's not going to matter that you're compatible.

[TonyGlover]

Thanks earlevel for the information posted. These refer to the minimum OS of the respective DAWs. However, once installed, DAW can run compiled plugins on the old xcode versions. I have not tested but theoretically a compiled plugin on xcode 3.1 has to go through all the daws listed by you.

Moreover, lot of musicians are known to be very lazy about updating their programs. There are many who use old programs that can not run compiled plugins on new xcode versions.

Here are many users who successfully compiled on xcode 3.1 maybe someone can give me a helping hand.

I wonder how it is possible to be an error that appears in the SDK of xcode

[earlevel]

Originally Posted by TonyGlover

Thanks earlevel for the information posted. These refer to the minimum OS of the respective DAWs. However, once installed, DAW can run compiled plugins on the old xcode versions. I have not tested but theoretically a compiled plugin on xcode 3.1 has to go through all the daws listed by you.

I think you missed my point, Tony. What I was saying is that DAW manufacturers have more incentive to support older gear than do plugin authors—people running ancient installations are generally doing so because it works and they don't want to change. They aren't the biggest group of people looking for the next awesome plugin. But it was a small point.

More important is what companies are actually developing. I was commissioned to write a set of plugins two years ago. In the contract, the well-known company I developed them for set the OS requirements as OS X 10.8, and Windows 7. Two years ago. Manufacturers just aren't keen on answering tech and installation questions from someone with an 8-year-old computer that they haven't been keeping current.

Now, you could develop a plugin that is compatible with 10.5.8 through 10.12 (Sierra). (Although I think you're saying that if you target 10.5.8, you will certainly be compatible with all and probably more going forward—I don't think that's necessarily true, but have no motivation to look for reasons.)

But, consider this: If everyone else's new plugins only run on 10.8 and up, what's the point of making the effort to stay in the stone age? So some user somewhere can run your plugin on their ancient system while not being able to run hardly any others?

Please don't interpret this as having some "tone"—I just think it would benefit you to think about why you are doing this. I don't think you're right that staying old will making you more compatible, particularly on Apple's products. They cut bait a lot sooner than Microsoft. I have an early-2009 Mac Pro 8-core, outfitted with SSDs and a couple of HD LCD monitors. I can't run Sierra on it, Apple no longer supports it. Not because it's too slow, but because they simply dropped support for Nehalem processors.

[TonyGlover]

I'm not familiar with Apple too much seems to be a big problem with compatibility as you say.

So what minimum OS-X system must I use to compile AU plugins to have maximum compatibilities?

[earlevel]

Originally Posted by TonyGlover

I'm not familiar with Apple too much seems to be a big problem with compatibility as you say.

So what minimum OS-X system must I use to compile AU plugins to have maximum compatibilities?

I don't know what the minimum is. I don't think that's the most important consideration, though. Building under 10.8 doesn't necessarily mean it won't run under 10.6.8, unless you code support for a feature that requires 10.8. That's unlikely, because you're relying on the IPlug framework for most non-audio/midi features.

So, I think the most important consideration—as far as minimum—is Plug's minimum requirements. If you can't build IPlug, you're probably trying to go back too far.

The biggest changes over the years for Mac, as far as plugins, have been carbon vs cocoa GUI, and 32/64-bit support. Hosts have been supporting cocoa GUIs long before carbon GUIs became obsolete, so there is no point in trying to go with ancient SDKs for carbon support.

64-bit Mac hosts, in general do not support 32-bit plugins (there are work-arounds), so you can't just put out a 32-bit plugin and think you'll have max compatibility. But it's easy enough to generate 32- and 64-bit versions. (I don't support 32-bit.)

I'd think that the only reason to build IPlug with an SDK less than 10.7 is to support Carbon GUIs. And Carbon GUI support make no sense at this point.

You can go forward trying to build with SDK 10.5 and Xcode 3.1. My comments have been mainly to "I know it's old but theoretically offer maximum of compatibility". You might be on your own, though, as there's not a lot of motivation for people to keep IPlug compiling under old Xcode and SDKs for Mac.

[Youlean]

Originally Posted by earlevel

I don't know what the minimum is. I don't think that's the most important consideration, though. Building under 10.8 doesn't necessarily mean it won't run under 10.6.8, unless you code support for a feature that requires 10.8. That's unlikely, because you're relying on the IPlug framework for most non-audio/midi features.

So, I think the most important consideration—as far as minimum—is Plug's minimum requirements. If you can't build IPlug, you're probably trying to go back too far.

The biggest changes over the years for Mac, as far as plugins, have been carbon vs cocoa GUI, and 32/64-bit support. Hosts have been supporting cocoa GUIs long before carbon GUIs became obsolete, so there is no point in trying to go with ancient SDKs for carbon support.

64-bit Mac hosts, in general do not support 32-bit plugins (there are work-arounds), so you can't just put out a 32-bit plugin and think you'll have max compatibility. But it's easy enough to generate 32- and 64-bit versions. (I don't support 32-bit.)

I'd think that the only reason to build IPlug with an SDK less than 10.7 is to support Carbon GUIs. And Carbon GUI support make no sense at this point.

You can go forward trying to build with SDK 10.5 and Xcode 3.1. My comments have been mainly to "I know it's old but theoretically offer maximum of compatibility". You might be on your own, though, as there's not a lot of motivation for people to keep IPlug compiling under old Xcode and SDKs for Mac.

Indeed, like earlevel said. But you should use latest macOS and XCode with old SDK (like 10.5) if you want to support old operating systems. The best bet to choose SDK is to use same version as your oldest supported operating system. BTW, you can also use 10.12 SDK and target 10.7 without the problem.

[Tale]

Originally Posted by TonyGlover

So what minimum OS-X system must I use to compile AU plugins to have maximum compatibilities?

Latest Xcode (8.2 or so?), and then run XcodeLegacy to install older SDKs. Then you should still be able to support OSX 10.5.

[TonyGlover]

How much help do I get! Thank you very much.

Finally, I success compile on the Tale version:

- PowerPC G5
- framework WDL - Tale
- OS X 10.5.8, XCode 3.1

Worked on OS X 10.5.8 also OS X 10.7.5 (x64 version)

I attach the result. Maybe someone with a more recent system checks it. It would be very helpful


IplugExample.zip

[Tale]

Originally Posted by TonyGlover

Maybe someone with a more recent system checks it. It would be very helpful

AU & VST2 x64 working fine here in REAPER on OSX 10.11.6.

[TonyGlover]

Originally Posted by Tale

AU & VST2 x64 working fine here in REAPER on OSX 10.11.6.

This is great, thanks Tale

[TonyGlover]

I'm back with Bundle unique ID problem. If I change the name from Schwa to my name the plugin crash the DAW. What is the secret of this unique ID Do I have to register somewhere?

Specifically, I have modified the .plist file the same with resource.h

	<key>CFBundleIdentifier</key>
	<string>com.Schwa.audiounit.IPlugExample</string>

to

	<key>CFBundleIdentifier</key>
	<string>com.Tony.audiounit.IPlugExample</string>

#define BUNDLE_DOMAIN "com.Tony" on resource.h

[1eqinfinity]

Thanks Earlevel. I'm in the middle of the adventure of porting my plugin to Mac, and you layed out things in a very clear way.