April 3, 2014
I only tried 32 bit as I tested with RackAFX, not a plain VST plugin.
The "multithreaded" library refers to the c++ CRT library which used to exist as single-threaded and mutli-threaded version until Visual Studio 2008 AFAIR. Newer versions only have the multi-threaded CRT, so this is nothing you need to care about with newer compilers. You won't need to use multiple threads for multiple midi connections, you just can call "getMessage" sequentially for multiple ports.
The MMSYSERR_ALLOCATED code looks like the driver is already in use by your process. What may be the problem is that the operating system only sees one process (your DAW) that already has openened the midi port, so you can't open it again from your plugin (which from the operating system's point of view is still the same process). What you could do in this case is to spawn a process from your plugin and do midi from there and use some interprocess-communication between the plugin and that "midi process" to connect them. However, if you can route the MIDI yoke ports accordingly it may be easier to use dedicated ports.
September 14, 2015
Thank you for your answer. You helped me go into the right direction.
I tried RackAFX. I could open the port and send midi and I could even debug with RackAFX.
Then I returned to my old project and suddenly it worked as well. And then suddenly it didn't after
a few compiles. There is definitely something strange going on when I use my host as the debug command . I hope I can pinpoint it in the future.
One thing was very strange though. Running the RackAfx project gave me all the ports including the Midi Yoke ports.
Running the SDK test project didn't give me the Midi Yoke ports. Don't even know where to begin with that. 😀
The most important thing at this moment is that I managed to send a midi message. Now what I need to do is populate 2 listboxes with the input and output ports.
February 7, 2017
W Pirkle said
To transmit a Note On event, you would add this to the end of the process( ) method:
// --- get the event list for output
IEventList* outputEvents = data.outputEvents;
(Thanks for all of your help, Will!)
I would like to know more about ownership of the output IEventList (I see that it's pure virtual for one). The Steinberg docs and example code are either hopelessly silent on the matter, or I have missed some valuable source of information.
When I step into my plugin, data.outputEvents is a null pointer in the process() method. Should I create a member of type CVSTMidiEventList (which I see overrides the virtual methods in IEventList) and assign its pointer to data.outputEvents? What about lifecycle management of outputEvents? Etc....
Should I ask this on the Steinberg forums?
January 28, 2017
You need to setup an output port for MIDI. In the VSTProcessor::Initialize( ) function, add the port
addEventOutput(STR16("Event Output"), 16);
Then your data output pointer will be non-null. You are highly limited to the kind of MIDI data you can send. See the fourth post at the top of this thread
Most Users Ever Online: 55
Currently Browsing this Page:
Guest Posters: 1
Newest Members:LamebrainEddy, SteveThackery, rawbirdtoe, Bill, hill william, NAUN_SONAR, sufy, Diane, Richard, drvenkman
Moderators: W Pirkle: 259
Administrators: Tom: 67, JD Young: 80, Will Pirkle: 0, W Pirkle: 259