startTimer failure when intialising Mac plug-in


Hi Jules,

I’ve just updated my various projects to use Juce 1.5, and Mixtikl is failing on the Mac for VSTi/AU - whereas the stand-alone versions (and the Noatikl plug-ins) are all fine.

The reason is that within my response to createEditorIfNeeded, I call Timer::startTimer (which I use for triggering various things including repaints). This is in Thread 1. However: my callback however is never executed! Actually, from that point on, it appears that the code in juce_Timer.cpp run() method is never reached after that point. So my app never repaints itself.

More checking: according to the debugger, the internal timer’s handleAsyncUpdate is never actually reached…! despite the call to triggerAsyncUpdate() in the constructor … so that explains why the run() loop doesn’t fire my timer.

Looks to me as though the message posted in triggerAsyncUpdate is never actually picked-up. NB the internal timer is never deleted, so something is up (presumably) within whatever message pump mechanism you use.

And any ideas of a work-around? I’m a little stumped…!!



I was also facing similar problem.

I m usng the dll created using juce. In that Dll i called initializeJuce_GUI() ,nitializeJuce_NonGUI() and shutdownJuce_GUI() , shutdownJuce_NonGUI() imethod.

When i say play in the main app i used to start the timer in the main app which is used to repaint the position of the seekbar. but some reason i never got the timercallback from juce.

I commented the initializeJuce_GUI, initializeJuce_NonGUI () and shutdownJuce_GUI() , shutdownJuce_NonGUI() methods in my dll.
Everything worked fine. I m getting my timercallback.

I Guess there is something wrong in those calls. I dint go into depth.
try commenting out any of these calls in ur code.

Can u please check this issue.


Hi Godwin, was your problem on Win, Mac or Linux…?



The problem was in MAC.
But with those initialization code in Pc was working fine. So the actual bug arises in Mac i guess.


Thanks for that info - yes, I think you’re right. I hope Jules can fix it pronto. :slight_smile:



I’m not quite clear which methods exactly you’re removing to make it work…

Obviously the plugin has to call initialise/shutdown correctly, but that’s all done automatically inside the plugin code. Had you added your own calls to these functions as well?


Hi Jules,

Just stepping-back a bit; I tracked-down the problem to be that the call to triggerAsyncUpdate() in Juce’s internal timer code never gets responded to. In other words, triggerAsyncUpdate() is called, but doesn’t result in the timer callback happening; does that help isolate the source of the problem?




Well, if shutdownJuce_GUI had been called too soon, then that’d certainly prevent these messages from getting delivered, but so could other things… What host are you using?


Hi Jules,

I have the same problem with both:

  • Logic Pro 8
  • Garage Band

I haven’t got any other DAWs on my Mac…

NB: Logic eventually can start the timer, I haven’t figured out the pattern there yet… no such luck with Garage Band.




Weird. And it’s only AUs, right? VSTs work ok?


Hi Jules,

Mixtikl AU: component doesn’t display (as the timer events don’t fire) in Garage Band; also doesn’t display in Logic 8, though I’ve actually seen it respond once or twice, maybe by Cmd-tabbing to another app and back (not sure about this - but I couldn’t get it to work this way at all with AU in Garage Band)

Mixtikl VSTi: well, Garage Band doesn’t display VSTs … but it crashes in cocoa land in a weird place on Kore 2 demo soonish after start-up

Actually, the VSTi was what I tried first, under Logic. When I saw it crashing very weirdly, I decided to try the AU, as then I could use both Logic and Garage Band as the test, figuring that any problems were likely to be common between both VSTi and AU … which is when I saw the timer problem in Garage Band!

Noatikl VSTi/AU: both OK (I think!).

I guess I’m going to have to try to figure-out how triggerAsyncUpdate() works. :slight_smile:

Best wishes,



Hi Jules,
I m not using any plugins. But i have my own Engine which renders the audio to the device where i used the juce audio code for reading , mixing and all.
The UI is also created using the Juce code. So when i hit play play in the UI i call the play method in the Engine DLL, and i start one timer i the UI to get the current sample position from the Engine to update my seek bar.

Now problem was i m not able to get the timerCallback method in the mac osx 10.5 machine. The same code was working fine in Windows Xp machine.

I have used the Initialization methods in the Engine DLL ( static library in mac ).
Confused about this weird problem, i just tried commenting those initialization code in my engine DLL( also shut down code ).

For my luck the app was stable and i m getting the timerCallback properly and my seekbar is moving.

i Seriously suppose there is something wrong i the initialization calls though i m not sure.



Hmm - interesting!

I’ve noticed for a long time now that with Mixtikl standalone (which is a standalone Juce app), the Mac version takes a lot longer to display the initial screen compared to the Windows version. I’d just never thought to mention this to you… put it down to being just “one of those things”.

However: I wouldn’t be surprised if these problems are all symptoms of a common underlying problem in the Juce timer code on Mac; I wonder if something in Juce’s Mac bindings blocks the delivery of the internal async triggers until some magic state changes in the underlying Cocoa framework. :slight_smile:




Ok, well that just sounds like you had some conflicting calls to the startup/shutdown code, or some kind of cross-linking problem.

…not impossible, but it seems unlikely. NSEvents can get blocked sometimes, depending on the run loop state, but the callbacks are sent via obj-c performSelectorOnMainThread: calls, which should always get through. Unless perhaps your app it sitting there until there’s a mouse-move event, and then the UI appears?


Good idea, but not AFAIK… when the Component gets created via the filter, I simply kick-off the timer via the setTimer method, and then return control back to the host.

Wrt your thoughts about performSelectorOnMainThread (which I happen to use on iPhone quite a bit!), that makes me presume that something, somewhere is blocking the main UI thread. I just wonder what that could be… and wonder how to spot it with the debugger!



These are cocoa hosts, so they should always be doing their run loop properly… And I don’t think performSelector can be blocked by modal loops. Hmm. I’ll have a think about it.


I don’t suppose this is anything to do with the problem, but I noticed that the use of asyncMessagePending as a guard variable in AsyncUpdater isn’t protected by a Mutex?



[quote=“peteatjuce”]I don’t suppose this is anything to do with the problem, but I noticed that the use of asyncMessagePending as a guard variable in AsyncUpdater isn’t protected by a Mutex?


No, that’s intentional.


Hi Jules,

OK, here is what I’ve found with the debugger. And it has me stumped. :slight_smile:

In …

I can set a breakpoint triggered in the init method for JuceAppDelegate, and that gets hit (once) OK.

When the timer is requested via setTimer, we end-up in juce_postMessageToSystemQueue(…), where the call is made to performSelectorOnMainThread

However: I cannot get a breakpoint on the entry to the method “- (void) customEvent: (id) n” to be hit!

If I change the call to performSelectorOnMainThread to pass YES rather than NO (to force it to wait until the event is handled)… the code returns immediately, but the entry point to “- (void) customEvent: (id) n” still isn’t hit!!!

I’m totally stumped now… haven’t a clue what to try next.



Is this in your initialisation code? Maybe it can’t do performSelector until the main run loop has begun?