VSTiBox is a synthesizer for hosting VST software synths.

Similar projects worth following
As a keyboard player I needed a new setup a few years ago. I was faced with the choice to either buy a VST host setup with many off-the-shelf components like a Macbook, audio interface and midi controller, or go for the DIY solution in which I could put everything in one dedicted musical instrument. This meant building everything in one custom made enclosure, writing my own VST host software and building my own control interfaces with all the features that I wanted to have. I chose the second option and started designing and building the VSTiBox. The VSTiBox is a Windows based machine that has the power to run the most heavy VST's, while interacting with it like a musical instrument. Because everything is integrated, it is easy to bring to a rehearsal or gig and hook it up. Check out my github for full source and design files:


  • All-in-one solution for playing VST instruments
  • Dedicated for live-performance with rotary controls and buttons
  • Real-time control of 8 VST instrument and effect channels
  • Midi input
  • Integrated mixer with multiple I/O and headpones output  
  • Switching between songs/banks
  • Setlist editor with song/bank selection
  • Powerfull PC platform for heavy VST's 
  • Low latency audio


You might ask why I didn’t buy a VST control keyboard like the AKAI Advance or Native Instruments S61 mkIII. Those are excellent midi controllers especially made for playing VSTi’s. The reason is because I would still need a separate laptop/MacBook, mixer and audio interface and hook them all up with the midi, audio and power cables. Other solutions exist like the V-machine and vPed, but they lack the processing power of my Intel I5. A Muse Receptor is also not an option because it is something you put in a rack, and not on top of your keys. It is also above my budget. The AKAI MPC (X) is looks awesome, but cannot run VSTi plugins standalone without a PC. I want to have an all-in-one solution, transport as few things as possible and plug in as few cables as possible when I go to a rehearsal or gig. 


The VSTiBox is build around a Windows machine equipped with an PCI Express audio interface, that runs a custom VST host (DAW) written in C#. The VST host receives midi input from a master keyboard, in my case a Nord Stage EX. Eight VST instrument channels are controlled by a number of encoders and RGB illuminated buttons for setting their volume and toggling the channel on and off. The audio ouput of the audio interface is routed through a mixer. The mixer combines the VSTiBox audio with two external stereo channels before it is sent to the master and headphone output. It also features a monitor input that is not routed to the master output, but only to the headphone for use on stage. The mixer is powered by a linear power supply which is a slave of the ATX computer supply.  Besides the PC platform and the audio interface, all components are DIY.


When playing live VSTi's you want to focus on playing and be able to switch sounds instantly by reaching for physical knobs and buttons which clearly show their state or value. Mouse handling or touchscreen presses are prone to error and therefore out of the question during a gig. This is why the system has no touchscreen. It does have a wireless mouse and keyboard connection for preparing banks and setlists. Although my original plan was to have no touch support, I now miss it very much and plan on adding it. Inspired by the Elysium C# controls theme, I designed an interface where a physical encoder is positioned directly under the screen, and the value of the encoder (volume/pan) is directly displayed graphically above the knob. 

Obviously the audio latency must be as low as possible. The ESI Juli@ XTe with PCIEXpress has a single +4dB balanced stereo in- and output with a perfect low latency. It is the first affordable low latency interface I could find thanks to this performance benchmark.

The Juli@ is mouted on a micro ATX Asrock B85M running an Intel Core i5 4460 with 8GB DDR3, which was a prefectly good choice back in 2014. Cooling is provided by a copper Zalman CNPS8900. It is equipped with a 256GB SSD, with an aditional one added later. 

  • 4 × Control interface boards 4x 24PPR encoders and 4x RGB silicon pad buttons
  • 1 × Audio mixer Multiple I/O and headphones out
  • 1 × Linear low-noise PSU 230Vac in, +/-12Vdc out
  • 1 × Wooden/acrylic case Table-sawed multiplex and lasercut acrylic
  • 1 × VST host software Written in C#, based on VST.NET

View all 6 components

  • Fatar keyboard prototype

    Jan Bert10/18/2018 at 19:55 0 comments

    For the 61TP/9S Fatar keyboard I could not find a good 3D model. I did find a dwg, but it is a flattened view of a 3D model and very difficult to convert to a 3D model. Therefore I decided to build a prototype just to get the dimensions for the keyboard right. I ordered some multiplex panels at my local hardware store and put together something quick and dirty. There are no detailed drawings; I just put some numbers on paper to make it big enough. On the left you see one of the two black Arturia Beatsteps. It is connected by midi over USB. I added support for multiple midi input devices in the VST host settings. The midi channel can now be selected for each VSTi channel. I'm using channel 1 for my Nord, channel 2 for the Fatar, and channel 3 for the Beatstep.

    Also, I wanted to know how the midi interface works before I put it in my final design. The interface has a few elliptical knobs that are used to select the midi channel, velocity and other settings. I dremelled out the elliptical holes in a 3mm sheet of triplex. In my final design I'm not going to make the LED display and buttons available on the outside. The board must be configured once correctly, and is then placed somewhere on the inside. It comes with a 12V 600mA adapter which I am not going to use. I will power the board with the 12V that comes from the ATX computer power supply.

    I have added some base paint and a few layers of black spray paint to make it look a bit better on stage. While the final VSTiBoard is still in development, this is acceptable as a temporary solution for me right now.

  • VSTiBoard materials

    Jan Bert10/18/2018 at 19:15 0 comments

    The VSTiBox is made of acrylic and multiplex. For the VSTiBoard I'd like to experiment with some new materials that I have never used before. The backside and panels above and below the Beatsteps will probably made out of thin multiplex covered in Tolex. This is the material that is used to build guitar amplifiers. I have ordered six samples to judge their look and feel. The last two samples in the row are what you typically find on the guitar amplifiers. I have chosen the first one in the row with the carbon look.

    For the wooden side-panels I'd like to use black American walnut. There is a fantastic woodshop in the big city I live in. The place is really nice to look around, and see all kinds of exotic wood. I have to get back there once my drawings are finalized. I’m not a woodworker so I am in doubt if I should hire a professional woodworker to machine the parts according to my drawings.

  • VSTiBoard interfaces

    Jan Bert10/17/2018 at 21:09 0 comments

    In my latest mechanical design I am using two black Arturia Beatsteps. The size of the Beatsteps causes the overall size of the synth to increase a bit. But this doesn't bother me. Because the Beatsteps have so many buttons and encoders, I am thinking of using the right Beatstep as menu interface instead of the 8 RGB buttons and menu encoder that is currently on the VSTiBox. 

    The increased width also creates a perfect space for the pitchbend and expression wheels.

    The space above the right Beatstep can be used to fit an audio interface and mixer. The problem with my current VSTiBox is that I do not have enough audio input and output channels. I currently do not have a MIC input for vocoder stuff, and I'm using the onboard soundcard + an additional 2 channel USB interface for a clicktrack and backingtrack output. The clicktrack and backingtrack outputs are not ASIO and that gives some time sync issues when starting the track. I have addressed this issue by manually adding some milliseconds delay in the VST host code, but this is not a pretty solution. I'd like to have have an audio interface that handles all input and output channels on the same asio buffer update handler. 

    My new requirements are:

    • 4x line input unblanaced
    • 1x MIC input
    • 1x Monitor input
    • 6x line output balanced
    • 1x headphones output
    • MIDI in

    I have drawn a schematic that shows the functional design of my ideal audio interface. The input and output channels have a visual indication on the audio levels. The MIC input and headhone output have a dedicated volume knob. All the other black virtual volume knobs can be controlled by a single big encoder, and some buttons to select the correct virtual volume knob. 

    To achieve this kind of functionality I’m considering two options:

    1. Buy a multichannel PCIExpress audio interface like an SERAPH 8 MWX or RME HDSPe AIO PCIe plus a separate MIC preamp and headphone amp. This is an expensive but time saving route.  
    2. DIY custom audio interface. In this way I can have the audio level indicators and volume control exactly the way I want it, and a formfactor which fits the VSTiBoard perfectly.

    At the moment I haven't decided yet what it’ll be, but I was recently inspired by freedsp. I have been in contact with one of the contributors and was gifted a bare PCB of the Infinitas. Awesome! The Infinitas is a working prototype of a USB audio interface with up to 32 in- and outputs. I've got the prototype with 2x freeDSPx-BAL-IO-x8 (also on Tindie). 

    For low latency audio I do not want to use USB, but Ethernet. A latency of less than 0.1ms with UDP over Ethernet is very possible on a Windows machine. I could build an Ethernet controller board with the volume encoders and display options exactly the way I want it. Then use the Infinitas DAC&ADC stage and add a separate MIC preamp and headhone amp. For the controller I'd choose an iMX RT1052 or SAM E70 Cortex M7. 

  • VSTiBoard

    Jan Bert10/17/2018 at 19:58 0 comments

    A single keyboard is often not enough when playing keys in a band. The VSTiBox supports a keyzone definition for each VST channel, but this results in way to many zones on my Nord. Also, there is no visual indication to where a zone starts and ends. I have to simply remember where each zone is. The Novation SL MkIII midi keyboard has a very neat feature to tackle this problem: RGB leds to indicate to which zone each key belongs to. Unfortunately my 1st gen Nord does not have this. My solution is to add a second keyboard. 

    Though I own an Access Virus KB, I’d rather not take it to a rehearsal or gig because it is just another piece of equipment that has to be hooked-up. The whole idea of the VSTiBox is to bring as few components as possible and to connect as few cables as needed. Another thing that I was missing when playing the VSTiBox was a drumpad to trigger some samples, and a few additional encoders to control the VST instruments or additional VST effect plugins in the signal chain. 
    Therefore I decided to design a new version of the VSTiBox: the VSTiBoard!

    This is my first attempt of the VSTiBoard, which has a keyboard and all the parts of the VSTiBox.


    After some browsing I decided to use a Fatar keyboard, because it simply has the best quality and feel you can get. It is also one of the very few keyboards which you can buy as OEM part. Some of the Fatar keyboards come with aftertouch. This is something that I want to have. So I tried to get a Novation SL mkII keyboard with aftertouch as service part from a local music shop. That didn’t work out. The only Fatar keyboard I could find was the 61TP/9S from, sadly without aftertouch. Maybe I can figure out a way to place a linear soft-pot (ribbon sensor) below the keys to build my own aftertouch. The advantage of using the keyboard from Doepfer is that they offer a board that converts the Fatar signals to midi, which includes the velocity calculation. I am not afraid to build this myself, but using off-the-shelf parts will save me a lot of time.


    This time I am using a touchscreen, because I was using my mouse way too often when defining a setlist, naming banks or checking out new VSTi’s. I have bought a 10.1” 1920x1200 LCD (B101UAN02.1) which comes with a very detailed manual that contains all the dimensions and tolerances, which is helpful for 3D development. 

     MIDI controllers

    In order to see which midi controllers suited my design best, I decided to draw them.

    In the image above you see a Steinberg UR28M, of which I thought was the perfect solution for an integrated mixer and audio interface. I bought a secondhand UR28M and tested it on the VSTiBox. The CPU load was 40% at idle! What was going on? 

    It turned out that the asio handler was called at a very irregular interval. I tried different buffersizes, driver updates, and even the asio4all driver. Nothing solved this issue. The ESI Juli@ does not have this problem and the asio handler is always called at almost the same interval, give or take a few ticks. When suddenly there is less time to process the VSTi's there is a big change that the buffer update is not handled in time which in return results in a crackling noise.

  • CPU load monitoring

    Jan Bert10/17/2018 at 19:38 0 comments

    There is a CPU load monitor in the bottom right of the main screen of the VST host. 

    It doesn’t show the overall CPU load like Windows Task Manager, but the actual system load for updating VST's and processing the audio buffers. The idea is to measure the duration of all the processing in the ASIO buffer update handler. To do this, a stopwatch is used which is restarted at the beginning of the handler. At the end of the handler function call, the elapsed time inside the handler is compared with the period of one ASIO buffer update, all measured in ticks.  

    private Stopwatch mCpuLoadStopWatch = new Stopwatch();
    stopWatchTicksForOneAsioBuffer = (long)(Stopwatch.Frequency / (mAsio.SampleRate / mAsioBuffSize));
    private void asio_BufferUpdateHandler(object sender, EventArgs e)
        ... VST processing and buffer updates
        int cpuLoad = 0;
        long elapsedTicksDuringHandler = mCpuLoadStopWatch.ElapsedTicks;
        cpuLoad = (int)(elapsedTicksDuringHandler * 100 / stopWatchTicksForOneAsioBuffer);
        if (cpuLoad > mMaxCpuLoad)
            mMaxCpuLoad = cpuLoad;

     The maximum CPU load is read and reset by the UI thread on a regular interval. The idle CPU load is currently 3%. This is a bit high. There are a number of things that are not so efficient here:

    1. The programmer :) I’m sure there are still many optimizations possible. I have not used any profiling tools yet. I’ve tried to use unsafe pointer based buffer handling as much as possible, but I have not deeply reviewed what I put together yet.

    2. The jump from unmanaged to managed C# code.

    3. Garbage collection.

    When running a single lightweight VST, the CPU load is about 8%. I'm thinking of rewriting the entire VST plugin and audio buffer update handling in C++. This would also allow me to implement multicore processing with a dedicated audio thread on each CPU core.  

  • Mechanical design

    Jan Bert09/08/2018 at 15:54 0 comments

    The biggest parts of the VSTiBox are a 10" LCD, the micro-ATX with the copper Zalman cooler and an ATX power supply that need to be stuffed in all one box. The top plate with LCD is put at an angle for better readability of the screen. The form-factor of the mixer matches this angle, with the volume controls on top and the TRS connectors on the back. 

    The LCD screen is covered with a 1/16" clear acrylic panel. The 1/16" clear panel has the same cutouts as the 3/16" black panel below it, except for the LCD. The square cutouts are for the silicon buttons. I dowloaded the stepfile for the silicon buttons and added some tolerance for the cut out. When assembling the top panel I noticed that the silicon buttons were a tight fit and needed at least 1mm more clearance. After a lot of tedious filing work on the black top panel, I did not want to work on the clear panel anymore, so it is currently not mounted.

    On the top left I added an illuminated power button. Below that are two control wheels for pitch bend and expression. Two 1/2" acrylic wheels are mounted on a potmeter shaft by a bolt on the bottom side in a threaded hole. The far end of the shaft ends in a bearing for strain relief. The bearing has a tight fit and is held in place by its surrounding components.

    The bottom and front plate are made of 14mm plywood which give the box it's strength. The back and topside are 3/16" black acrylic. The side panels are clear 1/2" acrylic which outer shape is slightly curved on all sides. I wanted the right side panel to be clear so you can see the DIY mixer. I choose a white PCB color, but maybe black would be the better choice. On the left side, two 80mm silent fans with low RPM are mounted (Noiseblocker BlackSilentFan X-1). 

    Below is a picture of the first boot of the computer after assembling it in the box. I did not measure the height of the fan correctly and had to dremel out some space in the 14mm bottom, which left about 5mm of wood below the area of the cooler mount.

  • C# VST host (DAW)

    Jan Bert09/07/2018 at 17:15 0 comments

    For quick prototyping C# is a great language. For highly optimized real-time audio processing C++ is the better choice. Nevertheless I wanted C# as the language for my custom VST host (often called DAW) because of the relatively quick development time and the large number of libraries that I could use. C# offers support for unmanaged code with which you can still use pointers to process audio in a relatively efficient way. 

    VST plugins

    I used VST.NET ( to load the VST plugins, write midi messages to it and get the audio buffer. The guy who wrote this stuff has put some serious time and development effort in it for which I am very grateful. The only downside is that plugin processing runs from a single dispatched thread. That means that all simultaneous VST's that run in my host are processed from that single thread. I think that the bigger VST's handle their own threading and this is not a problem, but when you are using VST's that only run on the thread from  which they are called, this is a serious downside. This problem is discussed in the forums and no solution exists. 

    I will keep my eye open for other VST host libraries written in C++, and am probably going to rewrite the whole audio processing in pure C++ and keep the GUI layer in C#. Nevertheless I am very pleased with the current performance of my software. I am able to run four heavy plugins simultaneously at a buffer size of 128 samples. Often I can use some more medium weight plugins and use all 8 channels. Effect plugins are also supported. I tested it briefly and it is basically working, but I consider it to be still under development.  


    For Asio handling I tested both BlueWave.Interop.Asio ( and NAudio. Both work fine, but the BlueWave performed better to my opinion. I say this with care because it could very well be the same code base. I haven't looked into the code behind the NAudio asio handling. The BlueWave project had a small bug with did not terminate the ASIO driver correctly at shutdown. This resulted in having to reboot every single time after shutting down a debug session in order to get the audio to work again. After I got tired of doing so, I decided to fix the bug. The updated source is on my github. 


    For MIDI input from my Nord and an Arturia Beatstep, I tried to use midi-dot-net ( Unfortunately the Juli@ does not support kernel32 winmm.dll midi! The only way I could get MIDI in and output was to use DirectMusic midi. For that I used ( 

    UI controls

    Most of the UI controls I have written myself. The ringslider above the physical encoder was one that was very specific. Also the scroll-list operated by the main menu encoder I build myself.  

    Hardware monitor

    To monitor the CPU temperature I used OpenHardwareMonitor ( which continuously displays the temperature in the main screen. When installing the CPU cooler I damaged the bearings and decided to just remove the power from the CPU cooler. Amazingly it always runs cool. Possibly beacuse of the airflow through the case. But because of this I wanted to see the CPU temperature at the main screen. 

    PDF Viewer

    Sheet music in PDF format can be added to a song (bank). I use PDFViewer from to to display it.

    Smooth instrument transition

    I personally find this the most interesting part to write, because I came up with a unique musical feature that I haven't found in other DAW software for live usage....

    Read more »

  • Controller

    Jan Bert09/07/2018 at 15:04 0 comments

    Below the LCD I needed 8 encoders in a row, with illuminated buttons below them. On the right side of the LCD, I also needed 8 illuminated buttons, but in a 4x2 configuration. Therefore I designed a custom PCB with 4 encoder inputs and 4 pads for silicon buttons each with an RGB led behind them. I bought the silicon buttons at Sparkfun.  

    The heart of the controller is a LPC1114 with the UART hooked up to a 4 pin header. Both sides of the PCB have the same header with power and UART RX+TX, so multiple controllers can be chained. The idea is that the controllers are hooked up in this way for receiving messages from the PC:

    • PC TX => Controller 1 RX 
    • Controller 1 TX => Controller 2 RX 
    • Controller 2 TX => Controller 3 RX 
    • Controller 3 TX => Controller 4 RX 

    And for transmitting messages to the PC:

    • Controller 4 TX => Controller 3 RX
    • Controller 3 TX => Controller 2 RX 
    • Controller 2 TX => Controller 1 RX 
    • Controller 1 TX => PC RX 

    That means that controllers 1-3 are acting as a relay. Message are received in a queue on interrupt basis, and also transmitted on interrupt basis to offload the CPU in all the passing messages from the other controllers. The protocol supports an incremental ID which is assigned during initialization. This ID is used in each message to communicate with the correct controller.

    The board also contains a SE95 for SPI temperature sensing. An OPA177S with two micro pots is added for reading the pitch wheel pots with an adjustable gain and offset, so the ADC can be used in almost its full range. 

    Unfortunately I made a mistake in the schematic and did not hook up the UART RX&TX to the microcontroller. That is why you can see the various thin green wires.

  • Low noise PSU

    Jan Bert09/06/2018 at 20:58 0 comments

    In order to check if the noise from the mixer originated from the +/-12Vdc ATX computer supply, I decided to build a standalone ultra low noise PSU that could fit in the VSTiBox case. Of course pre-build solutions were available from ebay&Ali, but they did not exactly fit my requirements and size restrictions.

    I wanted the PSU to be a slave of the ATX computer supply, and added a relay which is powered by 5V from the ATX. 

    The 230Vac input is filtered by 3 varistors, a common mode choke and some class Y caps. I choose a 5VA toriod transformer with 2x12Vac output. The output is rectified by very fast super low Vf schottky's  with 100nF in parallel, which acts as a snubber to prevent HF ringing. Another single HF snubber is placed after the bridge rectifier. The TPS7A4700 linear regulators are simply the best I could find in terms of noise. The output stage has several different caps, with one big 4700uF buffer.

    Because this is a 230Vac circuit, I made sure to separate the low voltage domain by at least 4mm, and the high voltage signals at least 2mm.

    This design is a first time right, with no modifications needed. I tried to measure it with a high-end scope with the probe set to 1:1 and AC input, but could not find any output noise. 

    When I powered the mixer with this ultra linear PSU instead of the ATX, the noise (which was already quite low) only slightly decreased. I think it now compares to other instruments like my Nord. Overall I'm pretty pleased with the result, though this ultra linear is an absolute overkill. If I were to design the power supply again specifically for the mixer, I would have chosen the same toroid and filtering, but a simple 2x LM317 will do just fine.

  • Mixer design

    Jan Bert09/06/2018 at 19:50 0 comments

    The ESI Juli@ audio interface provides a single stereo input and output. Simply providing TRS connectors to the backside of the enclosure for the audio interface isn't enough. A mixer is needed to combine the signal of my Nord stage and Access Virus kb with the VSTiBox output, and send only one stereo mix to the mixer table. When playing in more professional bands this is not an issue because the sound guys like to receive multiple separate synth channels so they can can make their own mix, but in the places I perform it is better to do the mixing myself. Also a headphone output is needed. A monitor input with signals from the rest of the bandmembers is routed to the headhpone output only. I made the following design of the audio routing for the mixer before diving into schema and pcb design: 

    In the final design the headphone output has moved to the backplane. Also the audio to the Juli@ is balanced. This is the first audio design I have ever made, but I got some help from an expert for which I am very thankful. I tried to design it reasonably HIFI, with no sacrifice on cheaper parts. 

    I did some research on good sounding opamps and settled for the LME49740 for quad and LM4562 for dual opamps. Generally I chose the feedback resistors to be <= 10k, and lower when possible, with a matching capacitor to create a low pass filter with -3dB at 150kHz just to prevent high frequent ringing. 

    The power supply consists of the TPS7A4501 positive and  TPS7A3301KC negative utra low noise linear regulators. Both have a 220uF low ESR tantalum buffer cap. I designed the power stage for +/-12Vdc input, and +/-10Vdc output, so all the opamps and the headphone amp operate on +/-10Vdc.

    The headphone amp is made of a pair of LME49600's, each with their own servo circuit for removing a DC component. 

    The output of the volume control potmeters have a 100k pull down to prevent a cracking noise when turning them. I chose audio tapered potmeters that fit on angled side of the pcb. The pcb has the same angle as the top side of the case. The back side contains 4 dual row stereo Neutrik connectors for in- and outputs which are mounted in place by a nut. The line inputs are routed through 4.7uF polyethylene WIMA caps (MKS2B051001N00MSSD) for decoupling which according to some HIFI forum posts sound best. For the same reason I have used metal film caps and through-hole resistors. That didn't bother my because I had to solder the PCB by hand anyway. It also made routing easier I think, because all the through-hole components create a kind of 3rd board layer. 

    During assembling and testing I discovered a few mistakes:

    1. The footprint of the  caps was wrong, but this was easily solved. 

    2. I made a mistake in copying the servo circuit for the LME49600 from its application note, which resulted in a damaged earphone. Fortunately not a damaged ear! 

    3. If I recall it correct there is an error in the gain of the input stage from the Juli@ (L+R balanced input). But I still have to figure that one out. For now I can sufficiently adjust the level with the volume potmeter.

    4. There is a mistake in one of the mounted resistors; the left and right master output differ 3dB. I'll have to fix that too. All the sound guys I have worked with are annoyed that they have to unbind their stereo channel and use separate gains for left and right. If you read this: I'm sorry ;)

    5. Noise. I can hear it very little, but I want it to be just dead silent. To figure this one out I have built a custom ultra low noise PSU instead of the +/-12Vdc coming from the ATX computer supply. I will discuss the PSU in a next log.

View all 10 project logs

  • 1
    Mechanical build

    Warning: if you want to build your own VSTiBox, please consider that the v1.0 design files contain some errors, but a manual workaround is possible. During the build process of my VSTiBox I came across a number of design mistakes which I have tried to document as much as possible in the project logs and build logs. The PCB versions which I have built are all v1.0. For the mixer and the control PCB's I have fixed these errors in the v1.1 schematics, but I have not finished routing the v1.1 PCB's yet. The mechanical design files also contain a few problems which I will describe in this build log. 

    The base of the VSTiBox are two 14mm multiplex plates. The dimensions for the two plates are 420x188mm and 420x102mm. I got the plates from my local hardware store, sawed to my specifications. The 102mm front plate needs to be sanded off, at the same angle as the top plate and mixer PCB. The plates are mounted together by 7 screws, evenly spaced. Fix the plates at an angle of 90 degrees, and align their sides. Use a hand drill to drill holes for the screws. Use a countersink drill bit to let the head of the screw fall within the front plate. 

    The micro-ATX with the CPU cooler mounted do not fit correctly in the case. The entire space beneath the motherboard needs about 3 more millimeters, and the space beneath the cooler needs to be dremeled out to a depth of about 9mm. After the two multiplex plates are screwed together, I used wood filler and sandpaper to get a flat surface. After a layer of base paint it can be painted with black spray paint.  

    The acrylic parts can be ordered online. All the drawings I used for ordering are in

    I use 3 different sizes: 1/16", 3/16" and 1/2" inch. The square cut-outs for the silicon buttons in the black and clear top panels need at least an additional 1mm clearance. This can be done manually, but it is better to update the design files. The acrylic sidepanels have a 4mm pilot hole. They need a counterbore to fit the screws - i think I used 10mm. Use the lasercut pilot holes to mark the drill positions on the multiplex plates. With the counterbore the screwhead sits at about 4mm from the back of the plate. The fans can be mounted on the acrylic side panel with the same counterbore screw holes. 

    The ATX PSU is glued in place by epoxy. The back and topside acrylic plates have drill holes for screws in a small piece of metal profile. Though I started making this profile, I have not finished them yet; the topside screws have never been mounted.  In front of the PSU there is place for two SSD's and the linear PSU. 

    The wiring is a bit off a mess, I know. This is something I did not plan in advance and just went with it. The white Juli@ audio interface above the CPU cooler is glued in place. This is not ideal and a neatly designed screw connection would be much better. The display is mounted by two scrap pieces of black acrylic. I later decided to fix it with silicone sealant. The display is a 10.1 inch TFT display from ebay. I thought is was a full HD display, but it turned out it was a 1280x800 display and I misread the ebay item details. It uses a 'HDMI+VGA+2AV Driver Board' which is glued in place with some epoxy. The power comes directly from on of the 12V lines from the ATX PSU. This somewhat problematic; sometimes the display does not start correctly which I think has something to do with the timing of the 12V power and the HDMI signal from the motherboard. The problem only occurs after it has not been used for a long time. A simple solution is to restart the computer. The display always functions normally after the second boot. 

  • 2
    Controller hardware

    The controller PCB's contain a lot of SMD components, but soldering by hand is do-able. It is best to start with the hardest part: the LPC1114. I use a technique to solder all the pins with a thick layer of tin. Then I hold the PCB at an angle of about 30 degrees, and let all the tin flow to my solder iron; away from the microcontroller. Use old fashioned leaded tin which is much easier to solder. You can also add some flux to make this easier.

    As described in the blogpost about the controller, I forgot to route the UART TX and RX to the LPC1114. The following image shows the green wires that have to be added manually to get it to work. The purple traces are not used anymore. The either have to be cut, or R4 and R10 have to be mounted in a vertical position on only one solder pad. The wire can then be connected to the other end of the resistor. I added schematic v1.1 that contains the fix to the GIT repository, but did not finish the routing. The ground planes are very thin at some points. A 4-layer board with a dedicated ground plane would be better. 

    The final connection to the PC is a USB serial device (like an FT232RL) with 3V3 TTL uart. In this way the VSTiBox host software can iterate over the available COM ports on the PC and automatically connect to the first controller.

    The biggest mistake I made with the controller and which cannot be fixed, is ordering a default PCB without gold finish. After a few years the pads for the silicon button will corrode and the contact gets worse with more jitter. My hardware is already suffering from this and I had to implement a pretty heavy debounce filter in software. A better choice would be to order the board with a gold finish, or even a graphene layer on the button contacts. The silicon buttons also have a conductive graphene ring.  

  • 3
    Controller software

    The c source in git/sw/control/src is build with Keil uVision. This IDE is free up to 32KB build size. The LPC1114 has exactly that amount of ROM so it can be fully used. A standard 10 pins 1.27mm SWD connector can be used to program it with a programmer like a JLINK or ULINK. I personally prefer the JLINK because it is very quick and has an API which can be accessed from .NET, but that's a different story. The following image shows the pinout of the SWD connector.

    When Control.uvproj file is opened in Keil, you first have to check if there is a SWD connection. Go to (1) 'Options for Target' => tab debug => Settings for you selected debugger. Make sure SWJ is enabled and SW (SWD) is selected. Now you should be able to see the core ID. Hit rebuild (2) and Load (3). 

    If the target is progammed once, you can only connect to it the first 3 seconds after powerup, because the SWD pins are used for driving the leds. To enable SWD debugging (and disable the led) uncomment the #define SWD.

View all 10 instructions

Enjoy this project?



steve wrote 03/11/2020 at 14:13 point

Brilliant!! and just the type of project I love.  I'm learning to write VST's (C++) at the moment and playing around with pureData.  Did you get around to re-writing C# to C++? or was C# good enough?

  Are you sure? yes | no

Jan Bert wrote 11/14/2020 at 13:16 point

Hi Steve, good question. I'm currently still running the C# version which is indeed good enough. I started working on the C++ rewrite a year ago but it is work in progress and will not be finished any time soon I guess. I have found more joy in creating a C++ synth VST plugin that is now taking all of my free time. Regards, Jan Bert

  Are you sure? yes | no

Craig Hissett wrote 10/13/2018 at 21:36 point

This is just phenomenal mate. Phenomenal!

I'd love to give something like this a go one day, but rather than using MIDI in use an XLR in; I am a trombone player and I'd love to have some all-in-one solution to be able to have fun when playing live.

In currently experimenting with a mixer, using the send from the channel to run through some multi fx pedals (Line6 Floorpod and a Yamaha Magicstomp) before returning to a separate channel on the mixer.

Without building a proper pedalboard it would be a pain to use, and running a software based setup would be much more intuitive for getting good results .

Awesome stuff man!

  Are you sure? yes | no

Jan Bert wrote 10/17/2018 at 21:47 point

Wow, thanks for your compliments! And good luck with your effect experiments.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates