Gui problem with Soundtrack Pro

Juce plugins, both the demo and my plugin, only open the first time in Soundtrack Pro when compiled with a target os of 10.4. When compiled with the target of 10.5 it works fine. Has anyone else seen this?

To reproduce:

  • juce plugin built with target os 10.4
  • running on os 10.6.3 intel, soundtrack pro 3.0.1
  • load a .wav
  • load a juce plugin and process the audio
  • load the juce plugin again and the gui never appears

I would really like to keep backwards compatibility with os 10.4 if possible.

Strange. Can’t think of any obvious differences between 10.4 and 10.5 that would do something like that…

It seems to be an issue with not being able to start a timer - when the editor is created, here is the call stack of the freeze on the second opening of the gui:

(just trying to generate a clean stack dump, will post soon…)

The only thing that seems like a likely candidate is in, where there’s an ifdef to work around a function that’s missing in 10.4. It has to use CFRunLoopGetCurrent instead of CFRunLoopGetMain, but perhaps SoundTrack is calling the startup code on a background thread, which would make that give the wrong answer…

Those names look familiar from the stack dump. I’m just trying to generate one from a clean build of the demo plugin to post here instead of my own plugin…

It’s actually a different stack trace for the demo plugin, it hits an assert in setVisible. This happens in the debug version of both the 10.4 and 10.5 version, but the 10.5 release version can battle on and get the gui to display but the 10.4 version can’t:

void Component::setVisible (bool shouldBeVisible)
if (flags.visibleFlag != shouldBeVisible)
// if component methods are being called from threads other than the message
// thread, you’ll need to use a MessageManagerLock object to make sure it’s thread-safe.
—> checkMessageManagerIsLocked
SafePointer safePointer (this);
flags.visibleFlag = shouldBeVisible;
internalRepaint (0, 0, getWidth(), getHeight());

#0 0x960f939a in Debugger
#1 0x0f59a83f in juce::Component::setVisible
#2 0x0f594fb6 in juce::Component::addAndMakeVisible
#3 0x0f596d86 in juce::Slider::lookAndFeelChanged
#4 0x0f5b0fdf in juce::Slider::Slider
#5 0x0f3af003 in JuceDemoPluginAudioProcessorEditor::JuceDemoPluginAudioProcessorEditor
#6 0x0f3acb66 in JuceDemoPluginAudioProcessor::createEditor
#7 0x0f46c127 in juce::AudioProcessor::createEditorIfNeeded
#8 0x0f6b489e in -[JuceDemoProjectAU_V1 uiViewForAudioUnit:withSize:]
#9 0x001ac06c in ??
#10 0x9648fabf in -[NSWindowController _windowDidLoad]
#11 0x9641d94c in -[NSWindowController window]
#12 0x0019fac9 in ??
#13 0x0019f7e7 in ??
#14 0x003453e3 in ??
#15 0x0032053a in ??
#16 0x964785c6 in -[NSApplication sendAction:to:from:]
#17 0x00a3e3b8 in -[NSProApplication sendAction:to:from:]
#18 0x96478479 in -[NSMenuItem _corePerformAction]
#19 0x9647816b in -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:]
#20 0x9647805a in -[NSMenu performActionForItemAtIndex:]
#21 0x9647800d in -[NSMenu _internalPerformActionForItemAtIndex:]
#22 0x96477f73 in -[NSMenuItem _internalPerformActionThroughMenuIfPossible]
#23 0x96477eb7 in -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:]
#24 0x9646c5f9 in NSSLMMenuEventHandler
#25 0x903f20a9 in DispatchEventToHandlers
#26 0x903f1370 in SendEventToEventTargetInternal
#27 0x90413b55 in SendEventToEventTarget
#28 0x90440147 in SendHICommandEvent
#29 0x90464e40 in SendMenuCommandWithContextAndModifiers
#30 0x90464df5 in SendMenuItemSelectedEvent
#31 0x90464cfa in FinishMenuSelection
#32 0x90434436 in MenuSelectCore
#33 0x90433ba4 in _HandleMenuSelection2
#34 0x904339c2 in _HandleMenuSelection
#35 0x96465b3a in _NSHandleCarbonMenuEvent
#36 0x9643a6e6 in _DPSNextEvent
#37 0x96439976 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
#38 0x963fbbef in -[NSApplication run]
#39 0x00a3eab1 in NSProApplicationMain
#40 0x002bcb53 in ??
#41 0x00003946 in ??

In my plugin the hang is when the editor is being created for the second time:

#0 0x987c3741 in CFRunLoopWakeUp
#1 0x0f8e150b in juce::AppDelegateRedirector::postMessage at
#2 0x0f6f4d8b in juce::juce_postMessageToSystemQueue at
#3 0x0f6f4db2 in juce::MessageManager::postMessageToQueue at juce_MessageManager.cpp:80
#4 0x0f7a2ba4 in juce::MessageListener::postMessage at juce_MessageListener.cpp:56
#5 0x0f7a80b3 in juce::AsyncUpdater::triggerAsyncUpdate at juce_AsyncUpdater.cpp:49
#6 0x0f90ef40 in juce::InternalTimerThread::InternalTimerThread at juce_Timer.cpp:52
#7 0x0f90efe4 in juce::InternalTimerThread::add at juce_Timer.cpp:186
#8 0x0f7cd2c2 in juce::timer::startTimer at juce_Timer.cpp:389
#9 0x0f81115c in juce::TooltipWindow::TooltipWindow at juce_TooltipWindow.cpp:50
#10 0x0f97b53b in Cytomic::BusCompEditorComponent::BusCompEditorComponent at BusCompEditor.cpp:1579
#11 0x0f97f058 in Cytomic::BusCompFilter::createEditor at BusCompEditor.cpp:129
#12 0x0f6f72ee in juce::AudioProcessor::createEditorIfNeeded at juce_AudioProcessor.cpp:268
#13 0x0f92f115 in -[CytomicTheGlueAU_V1 uiViewForAudioUnit:withSize:] at

Yeah, that all fits with my thoery above, it must be initialising it on a background thread. Bit hard to come up with a workaround for that - it needs to call CFRunLoopGetMain(), but that doesn’t exist in 10.4…

Here is the where the release version of the demo hangs:

#0 0x987c3741 in CFRunLoopWakeUp
#1 0x0f6152e9 in juce::juce_postMessageToSystemQueue
#2 0x0f4fd90d in juce::MessageManager::postMessageToQueue
#3 0x0f508c30 in juce::MessageListener::postMessage
#4 0x0f509d87 in juce::AsyncUpdater::triggerAsyncUpdate
#5 0x0f5a7d71 in juce::Component::setVisible
#6 0x0f5a8ebc in juce::Component::addAndMakeVisible
#7 0x0f5dc2ad in juce::Slider::lookAndFeelChanged
#8 0x0f5dc8e8 in juce::Slider::Slider
#9 0x0f48d7b0 in JuceDemoPluginAudioProcessorEditor::JuceDemoPluginAudioProcessorEditor
#10 0x0f48c1b1 in JuceDemoPluginAudioProcessor::createEditor
#11 0x0f50663a in juce::AudioProcessor::createEditorIfNeeded
#12 0x0f65ee4f in -[JuceDemoProjectAU_V1 uiViewForAudioUnit:withSize:]

Well, sounds like time to raise the minimum spec for intel builds to 10.5. I’ll see how many users scream.

It’d be fine if SoundTrack just initialised it on the main thread…

But I can’t find any way for a thread to determine the main run loop prior to 10.5 - even the cocoa classes only get methods to do that in 10.5.