startTimer failure when intialising Mac plug-in

I have found that if I subsequently capture a mouse click event on my component (which works fine!) and call startTimer… the problem continues to exist. (NB I didn’t try calling stopTimer first… dunno if that would affect things.)

If it were only safe to call startTimer after a certain point… how would I be able to detect that the point in question had passed?

Pete

just wondering, if this has been resolved?

Nope - I’m still stuck, and can’t figure out what might be going wrong. :frowning:

I need to figure-out a solution in the next 2-3 weeks, otherwise the initial launch of Mixtikl 2 won’t have an AU version. :slight_smile:

I wonder how many of us have encounted this? Is it just AU specific? FWIW in the past few days I’ve been able to build a Juce-based Browser Plug-in component with the same underlying code, without any problems…

Pete

It could be host-specific, though I’m baffled as to what could be going wrong…[/list]

Do any of the JuceAppDelegate methods get called? Maybe the #define JuceAppDelegate MakeObjCClassName(JuceAppDelegate) isn’t creating a unique @selector target and its sending the event to another plugin?

Just a thought…

Justin

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

Sorry I missed that…

EDIT2!: How about getting the address of self in the -init method and comparing that to the juceAppDelegate address that postMessageToQueue calls. Also, what’s your backtrace on the juce_postMessageToSystemQueue (type bt in Xcode’s console)

EDIT3: One more crazy idea, just before your start timer…

MessageManager::getInstance()->runDispatchLoopUntil(100);

This eventually calls [NSRunLoop currentRunLoop] which will create a run loop on the current thread(the message thread) if needed. If it works, i think it means something else is dodgy somewhere in your code, but its another idea to your puzzle!

Some good ideas there. Would be interested to hear the results…

Cheers for that Justin, some very helpful suggestions for me to investigate. I’ll keep you all posted. :slight_smile:

Pete

After a lot of fiddling round, I’m sorry to report that I’ve not really discovered anything.

Logic 8 (where the AU works), and Garage Band (where it doesn’t!), clearly have a different idea of how to implement the AU host protocol. Which is kind of funny, considering they are both made by Apple!

Anyways, I’m giving on on getting the AU working under Garage Band for now, I’ve pulled out too much hair with this…

What with the fun Jules and I had tracking-down browser plug-in issues under Safari 4 (separate thread…), audio problems in the latest iPhone 3.1.1 release, and the huge number of linker warnings in the XCode 3.2 “upgrade”, I’m not entirely happy with Apple right now! :roll:

Still: onwards and upwards! :slight_smile:

Pete

Yes… I’m not crazy about them right now either. I’ve just spent about 3 hours replacing all the deprecated CoreAudio functions with almost-identical functions that do the same job in a more long-winded way.

Hi Jules,

Just to note that having updated to Juce 1.52, my problems with Mixtikl running as an AU under GarageBand have now disappeared.

So, kudos to you - I don’t know what you fixed to make it work, but it now works for me. :slight_smile:

Best wishes,

Pete

I’ve also just experienced timers not working in my VST. Furthermore, mousewheel messages didn’t get received by the knobs either. This was on 10.6.

Which host?

Ableton Live 6. Forget about the mousewheel messages, though, my knobs are timer-repainted that’s why nothing happens when you turn the mousewheel over them.
I also found a way to reproduce the problem: I noticed that when you open the JuceDemoPlugin as AU (as often as you like), everything is ok. But as soon as you open the JuceDemoPlugin VST, after opening the AU one, the label that is supposed to show the song position will not appear. Same happens when you first open the VST version, then the AU version. Check it out.

Yeah, you’ve hit a flaw in the obj-C linking model. Discussed here:
http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=5738

It seems that, after having made 2 targets now, with different ObjC extra suffixes, it’s all good now, and that so far I didn’t experience any crashes when closing the host (as I did before). Is it possible that the host could have crashed because of this when closing (see this thread: http://rawmaterialsoftware.com/viewtopic.php?f=8&t=6431) ?

If you’d opened a VST and AU in the same session, then definitely. I’m surprised it’d even get as far as closing the app before crashing!

ok, thanks for the quick answer. so do you think i can now release my plugin to the public as update, without having hundreds of users shout at me for stability issues afterwards? or do you think this thread’s subject still needs a final answer?

Well, it sounds pretty certain that your problems were due to that AU/VST namespace clash.