Preview audio in VST without relying on ProcessBlock

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?


Thanks in advance for any suggestions.


~ Doron

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!

Hello and thanks for the fast response. 

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. 

Thanks again. 



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!

Just thinking of a metaphor...

got it. the processBlock method is constantly being called by the host even when its not "playing". this actually makes a ton of sense. 

water hose metaphor good too. 


Some hosts (Wavelab, Logic) won’t call processBlock() when playback is stopped. A workaround can be to enable input monitoring.

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.