Source code for the ConnectDAWs VST3 audio plugin which I developed as a Capstone Project at CODE University of Applied Sciences. The plugin allows you to connect two DAWs (digital audio workstations) via internet and stream audio between them. The goal is to stream audio with low latency to allow for real-time collaboration between musicians. The plugin is developed with the JUCE framework and Boost Asio. The plugin is still in development. The current version is a prototype with basic functionality and a lot of limitations.
The basic functionality includes:
-
connecting two running ConnectDAWs plugins on a local network
-
streaming audio between two connected plugins (with currently long latency)
-
basic GUI
-
error handling for connection and plugin configuration issues
Current biggest limitations:
-
only compatible with machines on the same local network
-
only compatible with ipV6 addresses
-
high latency
-
only compatible with Windows
-
has to be reloaded on audio device changes
Disclaimer: the project is currently only develped on Windows with the MSVC compiler. Developing on other platforms or other compilers might need additional configuration!
-
CMake 3.27 or higher
-
C++ 23 compiler
-
Clang-tidy & Clang-format (optional)
- Clone the repository --recursively to get the submodules:
$ git clone --recursive https://github.com/JosefLeinweber/ConnectDAWs-VSTPlugin.git
$ cd ConnectDAWs-VSTPlugin- Create a build directory and run CMake:
$ cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
$ cmake --build build --config Debug --target ALL_BUILDWhen building in Release mode, tests have to be disabled. This can be done by setting the option ENABLE_TESTING to OFF.
$ cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DENABLE_TESTING=OFF
$ cmake --build build --config Release --target ConnectDAWs_VST3$ cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
$ cmake --build build --config Debug --target ALL_BUILDor to build tests only change the target to ConnectDAWsUnitTests or ConnectDAWsIntegrationTests
$ ctest -T test --test-dir build/ -C Debug --output-on-failure
The VST3 plugin is based on the JUCE framework. The plugin is structured in three main parts: the core, the functional part and the user interface. The core part holds the juce plugin structure and intializes the functional part and the user interface. The functional part is responsible for the logic of the plugin, such as establishing a connection and streaming audio. The user interface is responsible for the visual representation of the plugin and the user interaction.
├── github/ # Github configuration and workflows
├── cmake/ # CMake functions and macros
├── external/ # External dependencies
├── src/ # Source files
│ ├── core/ # Juce Framework Plugin code
│ ├── functional/ # Logic of the plugin
│ ├── ui/ # User interface of the plugin
│ ├── utils/ # Utility
├── tests/ # Test files
│ ├── integration/ # Integration tests
│ ├── unit/ # Unit tests
├── tools/ # Tools for developmentThe JUCE AudioProcessor is responsible for the audio processing and the communication between the plugin and the DAW. The AudioProcessor has several methods that are called by the DAW, such as prepareToPlay, processBlock and releaseResources. The processBlock method is called in real-time and is responsible for processing the audio data. Every time the DAW processes a block of audio data, the processBlock method is called.
In the ConnectDAWs plugin the ConnectDAWsAudioProcessor derives from the JUCE AudioProcessor and implements the audio processing and the communication with the functional part of the plugin.
The following sequence diagram shows the an abstraction of the core functionality of the plugin.
- Get rid of hardcoded values, make them configurable in the plugin settings.
- Restructure testing. Most of current unit tests are integration tests, testing not one but at least two different units. Refactor the code to make it more testable.
- Create automated end-to-end tests to test the plugin as a whole.
- Instead of declaring classes in the header files, create interfaces in the header files and implement them in the cpp files. This will allow mocking the classes and their behavior in the tests.
- Use dependency injection to make the code more testable. This will make the constructor of the classes longer, but will allow to inject mock objects in the tests.
- Rework the message system between gui and cmt.
- Make sure the configuration data is encripted before sending them over the network.
- Analyze the security of the plugin, what do I need to secure? What are the risks?
- Develop a benchmarking tool to measure the latency of the plugin. Separate between the latency of the connection and the latency of the audio processing.
- Implement a method to connect two plugins on different networks.
- Try to decrease the latency of the audio streaming.
- CppProjectTemplate
- Author: franneck94
- Link: https://github.com/franneck94/CppProjectTemplate
- Wolfsounds Audio Plugin Template
- Author: JanWilczek
- Link: https://github.com/JanWilczek/audio-plugin-template


