C++:
VstIntPtr function dispatcher(AEffect* e, VstInt32 opcode, VstInt32 index, VstIntPtr value,
void* ptr, float opt);
Delphi:
function dispatcher(e: PAEffect; opcode, index: VstInt32; value: VstIntPtr; ptr: pointer;
opt: Single): VstIntPtr; cdecl;
always returns 0, unless otherwise defined.
all string-pointers points to zero terminated strings.
e[ ]: = plugin receives as entry parameter
x[ ]: = plugin returns to host
dispatcher() function using opcode 51:
51. effCanDo
>= VST2.0
@see AudioEffectX::canDo()
host queries a plugin's '"cando" capability
e[ptr]: string-pointer to cando string
x[return]: 1='cando', 0='don't know' (default), -1='No'
cando strings:
"sendVstEvents", plug-in will send Vst events to Host
"sendVstMidiEvent", plug-in will send MIDI events to Host
"receiveVstEvents", plug-in can receive MIDI events from Host
"receiveVstMidiEvent", plug-in can receive MIDI events from Host
"receiveVstTimeInfo", plug-in can receive Time info from Host
"offline", plug-in supports offline functions (offlineNotify, offlinePrepare, offlineRun)
"midiProgramNames", plug-in supports function getMidiProgramName ()
"bypass", plug-in supports function setBypass ()
C++ method:
VstInt32 AudioEffectX::canDo(char* text)
Delphi method:
function AudioEffectX.canDo(text: pchar): VstInt32;
Comments:
Report what the plug-in is able to do. In general you can but don't have to report whatever you support
or not support via canDo. Some application functionality may require some specific reply, but in that
case you will probably know. Best is to report whatever you know for sure. A Host application cannot
make assumptions about the presence of the new 2.x features of a plug-in. Ignoring this inquiry methods
and trying to access a 2.x feature from a 1.0 plug, or vice versa, will mean the plug-in or Host
application will break. It is not the end-users job to pick and choose which plug-ins can be supported
by which Host.
