Programming a VSTi host application

[Infms]

For my upcoming college computer science project I'm hoping to write a VSTi host application, something I've never done before. Does anyone here have experience writing one? What were the challenges involved? Is there any good documentation to refer to?

Thanks

[exh]

You can find various example hosts people have written around the net. Probably the most useful if you're using C++ is VSTHost (
http://www.hermannseib.com/english/vsthost.htm -- scroll to the bottom for the open source version).

I have one piece of advice: Don't start writing the host, instead first write a plugin, and examine how it works in a couple different hosts. It gives you a much clearer picture of how a host should work then randomly loading and poking at a bunch of VSTs and seeing what they do.

[aciddose]

a host is quite simple, maybe extremely simple.

you need several "modules" first.

- midi
- audio i/o
- a container for a plugin's information
- mutex

the host is built up of these parts:

- setting up the main window
- loading a plugin and connecting the various parts as required
- midi handling
- audio and midi routing (includes where you call process/processevents and output your audio)
- window processing loop where you call the plugin editors' idle functions

the hardest parts by far are the interfacing modules - if you already have those it should only take a day or two even if you've never used vst before. if you only want to load one plugin you can entirely skip the "plugin container" part. if you _do_ want to load multiple plugins at runtime and eventually connect them in more complex configurations you absolutely need to pay a lot of attention to that container's design, though.

your audio i/o and midi i/o modules might want to be dynamic eventually so you can have multiple input and outputs.

start simple though,

http://presetexchange.com/temp/advsthost.zip

this is a very simple single-plugin host i created just to test my own plugins. it at one time had a gui generator, but that code needs to be updated to get it working again. (it was a huge kludge, not done correctly)

it has the added functionality of a simple tone-generator that is automatically used if you load a midi plugin - in which case the midi will be processed by that plugin and routed to the tone generator.

the source doesn't include any of my interfacing modules.

this is a bad design - it works ok but i would recommend using a plugin container object of some sort and designing things with a little more modularity in mind.

also, whatever you do don't do what i do regarding reading the configuration file

the way i pass data around in that struct is also very bad - that stuff should be pointed to by the plugin container object if you write one.

[arakula]

The challenges involved... hm.

Challenge #1: you'll meet a lot of PlugIns which have their own view of the "VST standard". It's quite a challenge to get something working that allows most PlugIns to work correctly.

Challenge #2: to be of any use, the host program has to deal with both ends: it has to provide a base for the PlugIns, and on the other side it has to load and convert audio and MIDI to/from the devices. This lower end can become quite "funny", too... especially if you go the ASIO route. Great fun... here, too, are many different implementations, each with its own view how an ASIO driver should ideally behave. My most beloved ones are those for USB devices, and the behavior they expose whenever the USB device is not plugged into the PC... you can get everything from a protection exception over no reaction to correct error reports.

The biggest challenge, of course is the "something I've never done before" - what have you done before? How much experience do you have in coding in general, coding audio applications, coding MIDI applications, coding PlugIns? Each area has its own set of concepts that you have to become familiar with.

[Infms]

Thanks for all of the detailed replies. The application will only need to host a single VSTi synth plug-in, so to a certain extent I guess the host can be "build around" the particular VSTi - It will never be required to host any others. exh - Thanks, I'll browse through the VSTHost code. aciddose - Great to hear from your first hand experience, I've saved your code. If I wanted my host app to instruct the VSTi synth to play a note, would this be done via MIDI messages?

[aciddose]

yes, you probably should see my code for the basics if you just want to do a quick-and-dirty implementation. you don't really need to mess with things unless you want to support strangely behaved plugins. the majority of plugins work fine in my host and i don't do anything special, for example.

you'll need the vst aeffect.h struct definition and the aeffectx.h definitions file from vst2.4 (just google search for these filenames) to get things working roughly. as i said the most difficult part is getting the audio and midi i/o and windowing set up. loading and using the plugins is easy.

[Bramban]

Hello,

I am struggling with the same task. I've created audio i/o and tested. Compiled some vst plugins and at the moment the problem is between communication console application /vst plugin and how to apply that plugin into audio:)

[aciddose]

if looking at the source-code i posted doesn't help, your problem is likely related to your ability to deal with these sorts of issues from a programming perspective and not an issue of vst/audio/midi/etc. unless you have a specific question?

it takes time to learn these things, don't give up. feel free to ask specific questions - but it's not unusual to have difficulties at first. so don't expect anyone to give you a "magic answer" which answers all questions, as there are many questions with many answers, sometimes even multiple answers per question.