Steinberg VST SDK3
Steinberg VST SDK3
I am implementing VST3 in my Vst-Host.
All is well except that I do not know how to implement this :
"virtual tresult PLUGIN_API setComponentHandler (IComponentHandler* handler)"
This is like a callback, except it is in the form of an interface.
In the previous VST SDK (2.3/2.4) I had to pass 1 function pointer for the callback, but now, since all is implemented with interfaces, I have to pass an interface.
This interface has 4 virtual functions :
virtual tresult PLUGIN_API beginEdit (ParamID tag) = 0;
virtual tresult PLUGIN_API performEdit (ParamID tag, ParamValue valueNormalized) = 0;
virtual tresult PLUGIN_API endEdit (ParamID tag) = 0;
virtual tresult PLUGIN_API restartComponent (int32 flags) = 0;
The question is : how to translate this into 4 callback addresses?
All is well except that I do not know how to implement this :
"virtual tresult PLUGIN_API setComponentHandler (IComponentHandler* handler)"
This is like a callback, except it is in the form of an interface.
In the previous VST SDK (2.3/2.4) I had to pass 1 function pointer for the callback, but now, since all is implemented with interfaces, I have to pass an interface.
This interface has 4 virtual functions :
virtual tresult PLUGIN_API beginEdit (ParamID tag) = 0;
virtual tresult PLUGIN_API performEdit (ParamID tag, ParamValue valueNormalized) = 0;
virtual tresult PLUGIN_API endEdit (ParamID tag) = 0;
virtual tresult PLUGIN_API restartComponent (int32 flags) = 0;
The question is : how to translate this into 4 callback addresses?
looks like a regular interface with four functions, not four callbacks.
you would still just pass one pointer to the callback wouldn't you?
@handler?
from:
then pass 'handler' which would be the interface, is that not correct? sort of like a com object? Then just have one callback and pass handler to it?
I don't really know, just guessing, but it seems a lot of waste to have four callbacks just for one interface.
you would still just pass one pointer to the callback wouldn't you?
@handler?
from:
Code: Select all
Interface IComponentHandler
beginEdit(ParamID_tag)
performEdit(ParamID_tag, ParamValue_valueNormalized)
endEdit(ParamID_tag)
restartComponent(int32_flags)
EndInterface
Procedure My_Callback(handler_IComponentHandler)
<do something, etc...>
EndProcedure
setComponentHandler(@handler.IComponentHandler)
handler\beginEdit(ParamID_tag)
handler\performEdit(ParamID_tag, ParamValue_valueNormalized)
handler\endEdit(ParamID_tag)
handler\restartComponent(int32_flags)
My_Callback(handler)
I don't really know, just guessing, but it seems a lot of waste to have four callbacks just for one interface.
I didn't explain correctly...I don't really know, just guessing, but it seems a lot of waste to have four callbacks just for one interface.
In general :
When a DLL must communicate with a PB app, the PB app passes a function pointer to the DLL. Easy.
BUT now the DLL wants an interface instead of a function pointer.
Sure I can pass the address of this interface, but I don't see a link between this interface AND a PB callback function.
I think it's like ActiveX components with (cfr visual basic) the keyword "WithEvents"...
In this case it's not an ActiveX, it's a VST3 plugin.
Hope this makes sense?
I don't understand.
It is the plugin that will call the PB application (the host).
In this case the plugin will call :
- IComponentHandler\beginEdit()
- IComponentHandler\EndEdit()
- etc....
In SFSxOI sample I can't see how this could be established.
In other words : where is the link between :
"@handler" and "Procedure My_Callback()"
If you want, I can submit the code I already have.
(I can already open the plugin, query stuff etc...)
It is the plugin that will call the PB application (the host).
In this case the plugin will call :
- IComponentHandler\beginEdit()
- IComponentHandler\EndEdit()
- etc....
In SFSxOI sample I can't see how this could be established.
In other words : where is the link between :
"@handler" and "Procedure My_Callback()"
If you want, I can submit the code I already have.
(I can already open the plugin, query stuff etc...)
I don't see this way : if the plugin use the VSTGui and create something wich use the IComponentHandler, the plugin must implement these methods, then, the host wil call the setComponentHandler wich take the implemented method "filled" by the plugin, this is why this component is used a a callback and why these methods are virtual.
You can see this as a C struct with abstract methods functions pointer members.
You can see this as a C struct with abstract methods functions pointer members.
This is an excerpt of the C++ headerKarLKoX wrote:I don't see this way : if the plugin use the VSTGui and create something wich use the IComponentHandler, the plugin must implement these methods, then, the host wil call the setComponentHandler wich take the implemented method "filled" by the plugin, this is why this component is used a a callback and why these methods are virtual.
You can see this as a C struct with abstract methods functions pointer members.
//------------------------------------------------------------------------
// IComponentHandler Interface
//------------------------------------------------------------------------
/**
[host imp]
Host callback interface, used with edit controller*/
class IComponentHandler: public FUnknown
{
public:
//------------------------------------------------------------------------
/** Transfer parameter editing to component via host. */
/** To be called before calling a performEdit (when mouse down for example). */
virtual tresult PLUGIN_API beginEdit (ParamID tag) = 0;
/** Called between beginEdit and endEdit to inform the handler that a given parameter has a new value. */
virtual tresult PLUGIN_API performEdit (ParamID tag, ParamValue valueNormalized) = 0;
/** To be called after calling a performEdit (when mouse up for example). */
virtual tresult PLUGIN_API endEdit (ParamID tag) = 0;
/** Instruct host to restart the component. */
virtual tresult PLUGIN_API restartComponent (int32 flags) = 0;
//------------------------------------------------------------------------
static const FUID iid;
};
This interface is used to communicate with the HOST.
So, the question remains : how do I tell the plugin where to find those virtual functions?
I've tried with a structure (filling the members with the addresses of the PB procedures without any luck)
There must be some kind of way to do it I hope?
The easiest way is to forget about the Interface keyword (which is for using other interfaces) and use a regular structure:
Code: Select all
Structure SIInterface
FirstFunction.l
SecondFunction.l
EndStructure
Procedure Handler(*this.SIInterface, other arguments goes here)
EndProcedure
MyInterface.SIInterface
MyInterface\FirstFunction = @Handler()
MyInterface\SecondFunction = @Handler2()@Trond
That"s what I figured out too
I did it like this :
I gave the structure members the address of myHandler().
I even tried with different handlers (1 for every member) like this :
MyComponentHandler\myQueryInterface=@myQueryInterface()
....
But I get allways an invalid memory address when calling the plugins virtual function (IEditController\setComponentHandler(myComponentHandler).
I know that IEditController\Initialize(0) and other calls to member functions of IEditController work, so it certainly is a problem with the callback. I am wondering if this mechanism is even possible with PB?
I know that the plugin's call convention is cDecl AND
I tried both Procedure and ProcedureCDLL for the callback but without any luck.
The callback looks like this :
If you want i can pm you the code i have so far...
Thanks for trying to help me though
That"s what I figured out too
I did it like this :
Code: Select all
Interface IComponentHandler Extends iunknown
beginEdit (ParamID_tag)
performEdit (ParamID_tag, ParamValue_valueNormalized)
endEdit (ParamID_tag)
restartComponent (int32_flags)
EndInterface
Structure MyComponentHandler
myQueryInterface.l
myAddRef.l
myRelease.l
myBeginEdit.l
myPerformEdit.l
myEndEdit.l
myRestartComponent.l
EndStructure
I even tried with different handlers (1 for every member) like this :
MyComponentHandler\myQueryInterface=@myQueryInterface()
....
But I get allways an invalid memory address when calling the plugins virtual function (IEditController\setComponentHandler(myComponentHandler).
I know that IEditController\Initialize(0) and other calls to member functions of IEditController work, so it certainly is a problem with the callback. I am wondering if this mechanism is even possible with PB?
I know that the plugin's call convention is cDecl AND
I tried both Procedure and ProcedureCDLL for the callback but without any luck.
The callback looks like this :
Code: Select all
ProcedureCDLL myHandler(*this.myComponenthandler, p1.l=0, p2.l=0)
;code here>
endProcedureThanks for trying to help me though
it works
First define the interface
Then use a structure with a vTable
Then give the interface the address of the structure
Then tell the plugin to start communication with the host
The result is that the plugin calls myAddRef(*ptr) and myRelease(*ptr).
One thing I find strange is that the Callbacks in purebasic have to be defined as normal PB procedures.
I thought they should be C declared. (ProcedureCDLL)
Anyway, it works!
I love Purebasic!
First define the interface
Code: Select all
Interface IComponentHandler Extends iunknown
beginEdit (ParamID_tag)
performEdit (ParamID_tag, ParamValue_valueNormalized)
endEdit (ParamID_tag)
restartComponent (int32_flags)
EndInterfaceCode: Select all
Structure myStruct
*vTable
EndStructure
myStruct.myStruct\vtable=?VTable_
Datasection
VTable_:
Data.l @myQueryInterFace()
Data.l @myAddRef()
Data.l @myRelease()
Data.l @myBeginEdit()
Data.l @myPerformEdit()
Data.l @myEndEdit()
Data.l @myRestartComponent()
EndDataSection
Code: Select all
IComponentHandler=@myStructCode: Select all
Ret=IEditController\setComponentHandler(IComponentHandler)One thing I find strange is that the Callbacks in purebasic have to be defined as normal PB procedures.
I thought they should be C declared. (ProcedureCDLL)
Anyway, it works!
I love Purebasic!
-
karmacomposer
- Enthusiast

- Posts: 113
- Joined: Sun Jul 29, 2012 2:51 pm
Re: Steinberg VST SDK3
I need help - I am brand new to PureBasic and would like to CREATE a VSTi. Any guidance would be really helpful.
Mike
Mike
Re: Steinberg VST SDK3
Wait, that's not how this forum works! You already posted in numerous other threads that you want to do a VSTi and need help.
My advices for you:
1) Read the help file.
2) Learn and understand the basic syntax of PureBasic.
3) Also check out the many Get Started threads, tutorials, demo codes.
4) Get comfortable with the IDE: Features, projects, etc.
5) Do some basic programs, e.g. image manipulation and math for your audio processing.
6) Maybe then start your VSTi project.
Of course you can always ask specific questions here in the forum but just a plain "I need help for XYZ" isn't enough...
My advices for you:
1) Read the help file.
2) Learn and understand the basic syntax of PureBasic.
3) Also check out the many Get Started threads, tutorials, demo codes.
4) Get comfortable with the IDE: Features, projects, etc.
5) Do some basic programs, e.g. image manipulation and math for your audio processing.
6) Maybe then start your VSTi project.
Of course you can always ask specific questions here in the forum but just a plain "I need help for XYZ" isn't enough...
If any of you native English speakers have any suggestions for the above text, please let me know (via PM). Thanks!
-
karmacomposer
- Enthusiast

- Posts: 113
- Joined: Sun Jul 29, 2012 2:51 pm
Re: Steinberg VST SDK3
You are, of course, quite right. I am not a programming noob, however. Been programming most of my life, but not virtual instruments.c4s wrote:Wait, that's not how this forum works! You already posted in numerous other threads that you want to do a VSTi and need help.
My advices for you:
1) Read the help file.
2) Learn and understand the basic syntax of PureBasic.
3) Also check out the many Get Started threads, tutorials, demo codes.
4) Get comfortable with the IDE: Features, projects, etc.
5) Do some basic programs, e.g. image manipulation and math for your audio processing.
6) Maybe then start your VSTi project.
Of course you can always ask specific questions here in the forum but just a plain "I need help for XYZ" isn't enough...
I will be using PureBasic more for normal programs than anything else - normal meaning Database, Business and Custom apps for clientele
Virtual Instrument creation is important to me because I sell them (www.supersynths.com) and would like to not have to use Synthedit any
longer, so in a way, I am trying to fast track my way into getting started. I know I need to 'pay my dues' with PureBasic, but not really
when I have done so with several other languages. I guess i'm really just asking for directions or a head start more than anything.
Mike
Re: Steinberg VST SDK3
I gave up on VST3. Lost interest.
I still have a working VST2.4 plugin made in PureBasic (with UI but no dsp, just a MidiPlugin)
The code is quite old, and it needs still a lot of work...
(no preset handling, no Set/GetParameter, no code cleanup, no optimizations.....)
Anyway, if you want to make VSTI's, the hardest part is DSP!!!
Did you think about SynthEdit / SynthMaker or even the JUCE framework?
Have you downloaded the VST2.4 SDK from Steinberg?
Be also aware that the VST market is already quite overcrowded (to put it eufemistic...)
Anyway, good luck!
I still have a working VST2.4 plugin made in PureBasic (with UI but no dsp, just a MidiPlugin)
The code is quite old, and it needs still a lot of work...
(no preset handling, no Set/GetParameter, no code cleanup, no optimizations.....)
Anyway, if you want to make VSTI's, the hardest part is DSP!!!
Did you think about SynthEdit / SynthMaker or even the JUCE framework?
Have you downloaded the VST2.4 SDK from Steinberg?
Be also aware that the VST market is already quite overcrowded (to put it eufemistic...)
Anyway, good luck!

