Excellent detective work finding that interpolation problem! That’s an easy fix because there’s no reason why it’d need to be set to high quality for the gradients anyway - I’ll just set it to default mode.
I’ll try to do some more AU testing today and see if I can reproduce your crash.
A possible workaround might be to simply turn off the cocoa UI when running in 10.4…
If it’s a crash when it’s trying to load the obj-c UI class object, then a quick test would be to comment-out the kAudioUnitProperty_CocoaUI options in GetPropertyInfo and GetProperty. (Of course, it might be nothing to do with that - it’s impossible to tell from the stack trace)
Good to know I have only Live 8 on Tiger. It can proof that actually Cocoa UI is the problem for Tiger because as far as I remember Live supports Cocoa from 8.x
I’ve made the comments suggested by Jules and now it doesn’t crash I’ll test it more to check all the functionality.
I noticed also that if we want to run it on 10.4 we have to build the component with 10.5 SDK and compatibility set to 10.4. When I compiled it with 10.6 it still crashes on 10.4. The crash log is very similar as before.
Good. Well I’ve no qualms about nuking cocoa support on 10.4. I’d suggest these changes:
else if (inID == kAudioUnitProperty_CocoaUI)
{
#if MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_5
if (CFStringCreateWithBytesNoCopy != 0) // (Just a way of finding out if we're running in 10.5 or later)
#endif
{
outDataSize = sizeof (AudioUnitCocoaViewInfo);
outWritable = true;
return noErr;
}
}
and
[code] else if (inID == kAudioUnitProperty_CocoaUI)
{ #if MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_5
if (CFStringCreateWithBytesNoCopy != 0) // (Just a way of finding out if we’re running in 10.5 or later) #endif
{
const ScopedAutoReleasePool pool;
Maybe it would be nice to have those functions available as part of the SystemStats class, for a more complete control over MacOS X version returned by getOperatingSystemType