This project has moved and is read-only. For the latest updates, please go here.

Host port access / SysEx to Host

Topics: Midi, Plugin Development, VST.NET Framework
Oct 7, 2015 at 1:04 AM
Hey Vst-ers. I hope that everyone is well....

I have a couple of questions in the same ballpark, I wonder if anything rings a bell with anyone?

I've still fiddling around with my vst based SysEx editors. I have a vst midi-source which can fire channel-midi back to a host using the _plugin.Host.GetInstance<IVstMidiProcessor>() interface and calling Process with an event collection.

Question 1 Is - Should SysEx be processed by the host if I pass it back in the same collection ? Channel midi goes to an external synth ok when I create a midi track and route my vst output to the correct midi port. It doesn't seem to work at all and I'm not even sure if it is possible.

Question 2 - I've seen some professional plugins that 'Appear' to get a list of midi ports from a host and 'Seem' to be able to use them from within the plugin - I.e. piggybacking messages directly to an external device for instance. I can't see how this is possible from within the framework but I'm only starting to scratch the surface. Does this sound at all plausible ? I suppose you could site a service in between the port and host and interact with this (as a workaround).

Many thanks for the continued support and for making all of this possible.

Oct 7, 2015 at 7:54 AM
1) Most hosts have an option to block sys-ex from being processed - which is usually on by default. Check for that. Unless you have other midi plugins on that channel I would expect that any midi should go the the midi port assigned to that track. But this is very host-dependent. So check the manual/docs or ask online on their support forum.

2) I think they just open all the available midi ports on the PC and detect the ports that can't be opened because 'someone else' has it open already. Of course there is a backdoor in VST2.4 (and 3.x as well I think) where there can be undocumented plugin<->host communication (not supported by VST.NET). This allows a vendor of a host to supply plugins that will do things that is not possible with normal VST plugins.

As you're fiddling with midi: did you see my MIDI.NET project? ;-)

Hope it helps,
Oct 7, 2015 at 12:00 PM
Hey cheers Marc,

for your prompt and helpful response.

Yes I do wish that there was a development version of a pro host out there - a wasted wish I know :) I'll have to try and interpret the actual output from the midi port to see if anything is happening, I wonder if something like Midi Yoke would help with this....

I'll check out the DAW forum for Ableton and see how Bitwig or VstHost responds.

And yes I thought the use of host ports looked a bit - undocumented. I'll have to try and get a demo of one of these to see what they actually do...

If my adventure with SysEx and vst fails (for the moment) I'll definitely be looking for a midi solution and Midi.Net is at the top.


Where is the best place to review Vst documentation - I have the SDKs for 2.3, 2.4 and 3.x but the help there seems to be sketchy at best - is there a forum that you are aware of ?


many thanks as always...

Oct 7, 2015 at 12:43 PM
Yes Midi Yoke (never used it) or LoopBe1 ( can help you route the host (virtual) output to a (virtual) input of say MidiOx. That will allow you to unravel the Midi messages the host puts out.

Jah, the VST docs are notorious (bad). I know steinberg has a newsgroup / email list you can subscribe to to ask questions. Also kvraudio (.com) is an excellent forum on everything audio and VST.
Oct 7, 2015 at 7:46 PM
LoopBe it is, thanks Marc.