I'm trying to include a feature in my VST sampler that allows the user to preview a sound. I'm new to VST development, but it seems like the only way for a VST to render audio is to wait for a call to processBlock(). Is there a way to add this feature without relying on the host calling processBlock()? Alternatively, is there a way to indicate to the host that clicks on a certain region should induce a call to processBlock()?
In case I didn't do a good job explaining what I'm trying to accomplish, take a look at the drum rack instrument in ableton. You can hit the "play" triangle to hear any of the samples in the drum rack even when the transporter isn't moving. Is the only reason they're able to accomplish this because the drum rack is a native to ableton?
You're totally missing the point here... Yes, the only way to get audio out of the plugin is through processBlock, but that doesn't in any way stop you using it to play free samples or whatever you want, at any time you want!
I now understand that I should call processBlock on my own. I can feel myself moving closer to the point.
I believe my remaining confusion has to do with an improper understanding of the relationship between audio plugins and their host. In a very abstract sense, I imagine a plugin host as a program that continously creates audio sample buffers as time progresses, asks the various plugins and synthesizers to do some work to that audio sample buffer (in this case, by calling processBlock), and then render the final contents of the audio sample buffer.
In this (presumably flawed) architecture, there is no opportunity for the host to render audio sample buffers that are allocated by a plugin, and no way for the host to be aware of a call to processBlock that originates from a plugin.
Is it the case that plugin hosts are actually notified when a plugin makes a call to processBlock? This would explain why calling processBlock is the proper solution.
You can just drop frames / blocks from an audio buffer into the processBlock() method. I use this in a reverb plugin to playback sound samples so that the user can audition the reverb settings.
It is a callback function, called from a thread in the host (the audio thread). You cannot call it yourself.
Just see it as a water hose, constantly pumping in certain amounts of water. You can add colors to the water while it passes by, or replace it even with a different liquid ;-)
Just make sure to do all your stuff before the next shot of water comes through the hose!
I have a midi plugin whose processBlock also wasn't being called in Ableton unless midi events were being sent. I had a free running loop that was supposed to continue on each processBlock but would stop after the first cycle.
The workaround for me was using a MIDI LFO plugin right "in front" of my plugin to generate CC data for a CC # I wasn't using. This constant midi input (which I was ignoring) was enough to keep Ableton calling my plugin's processBlock.
I also noticed my processBlock would be called as long as the Editor window was open.
