It seems that GarageBand has the most issues out of all the DAWs I test. I’m currently trying to call some functions in prepareToPlay() to trigger demo mode of my plugin, but prepareToPlay() never even gets called. I even moved the function calls to trigger the demo more to processBlock() for the heck of it, but processBlock() isn’t being called either. Is this typical behavior of GarageBand? Or is GarageBand just being wonky for me? Anyone else have these kind of issues with GarageBand?
In Logic Pro X and in Garage Band, I think the prepareToPlay function is called at startup only, whereas in Reaper for example it is called every time you click on start on the transport bar.
However, processBlock is supposed to be used all the time, otherwise your plug-in wouldn’t do anything at all ! Your problem there sounds like a design issue with your code, instead of an issue from the DAW
ProcessBlock() is called the entire time I’m playing audio in VST Reaper and AU in reaper, but not AU in GarageBand. I have no clue what could be going wrong. In Xcode, I found the call heirarchy for processBlock() and put breakpoints all in every location that JUCE code calls processBlock(), 4 locations to be exact. None of these are even getting touched when running in garageband.
just a guess: if your plugin is an effect returning a getTailLengthSeconds() of 0, and if there is no audio signal going through your plugin, then GarageBand might just not call your process block. try to increase getTailLengthSeconds() or be sure you’re playing sound through your fx.
Also have a look at this thread:
Basically, Logic (& GarageBand) will not call your processBlock function if the transport is not playing. Only exception is if your plug-in is a synth and Logic detects midi coming in.
@fabian, well, processBlock() and prepareToPlay() aren’t getting called at any time, during playback or during standstill times.
Ill try the other suggestions provided, thanks all.
That’s just not possible. Are you sure you are loading the correct binary of your plug-in? (Try deleting your plug-in, open GarageBand to ensure it’s not available anymore and then re-build your plug-in). Are any other breakpoints being hit? Is your AU maybe being loaded in a sandbox and you are attaching to the wrong process?
I am new to coding on Mac, so forgive me if my suggestion makes no sense. But you say that your proof that it these functions are not being called is because the breakpoints aren’t being hit. I don’t know so much about Mac, but on PC, if you accidentally compile a release version instead of debug version, it will deliberately skip the breakpoints.
I’m positive I’m loading the correct binary. I just set a couple breakpoints in the processor constructor and did a debug in AU / GarageBand - no issues. They were caught just like they should, but not caught in the processBlock() and prepareToPlay() methods.
If it matters at all, my plugin does not process any audio whatsoever, but I do call my code to put the plugin in demo mode in these areas.
As for knowing whether or not its being sandboxed or attached to the wrong process, I’m afraid this is something I don’t know how to check.
Not sure if it matters or not, but my plugin does not process audio at all, not sure if that matters, but I am calling a few functions inside of prepareToPlay()…
getTtailLengthSeconds() is returning a value of 0 it seems.
I don’t know, if you checked that already, but if your plugin is an audio effect (aufx), and there is no audio on the track, then processBlock will not be called (also said in the thread fabian linked). It will, if you change it to be a generator afaik (augn).
Just copy some random audio into the track and see, if it is still not called…
I think I figured it out based off of @lalala, because my plugin doesn’t process audio, I have been testing it over and over on blank sessions. I didn’t need audio to test it. I recorded some audio and tested it and now it is working. Now I just need to figure out how to check for audio passing through I suppose.
Yep, this is what the problem was.
Well, I totally changed my implementation on this, since using prepareToPlay() or processBlock() are not totally reliable ways of starting and checking timers for a demo period, and understandably so, so I switched to using the Timer class, something I didn’t initially think of. Now, I’m having linker issues with AU for my timer class. I created a new class that inherited the Timer class and then created an instance of my new DemoTimer class in the private section of the audioprocessor class, but AU refuses to compile now unless I move that instance of DemoTimer to the .cpp file of the audio processor class, which is odd. VST compiles just fine and works.
When trying to compile AU with the DemoTimer object in the private section of the audio processor class, I get these:
linker error messages usually mean you didn’t implement a (virtual) method. the full error message is usually pretty specific, too.