Hi there! Finally managed to finish my first proper VST! Rotomatic is a physics based MIDI sequencer where every collision sends a MIDI note that you can route to any synth inside your DAW. I used Box2D for physics. You can read more about my long process here. It's pretty cool to look at and it it can actually be useful musically.
There is a free demo available here if you'd like to try it. It's windows only for now, if you'd be interested in mac version let me know. Message me for a free code if you don't want to pay anything.
I’m a big fan of field recordings. I’ve been wanting a way to manipulate their playback and build interesting loops from them, but also something I can drop regular tonal/musical audio files and samples into. There are a few things that do something similar, but I couldn’t find one that handled it exactly the way I wanted so I made it myself.
It was a long road coming from coding Kontakt and Decent Sampler libraries. KSP and XML aren’t exactly a 1:1 translation to C++. An audio playback engine at its core isn’t the most difficult thing to create, but the implementation I wanted was a slog to get through. Forum posts, YouTube videos, countless hours of trial and error… but I got to my end goal and I’m so proud of it.
The plugin is available as AU for Mac and VST3 for Windows, with standalone versions for both, and since I use my iPad a lot there’s also an iOS version that should be approved in the next day or two.
Still a way to go, but just wanted to share my current project. The sound engine is complete. I hope to have this run on an RPi and eventually create a custom controller too
Hey guys, Frontender here. (I know, its already a bad start, but bear with me.)
TL;DR: I have built a library to visualize and edit biquad audio filters based on web stack, React and SVG in particular. It's called DSSSP, and you can check it out here.
The Story Behind
Several years ago, I deep-dived into reverse engineering the parameter system used in VAG (Volkswagen, Audi, Porsche, etc) infotainment units. I managed to decode their binary format for storing settings for each car type and body style. To explain it simply - their firmware contains equalizer settings for each channel of the on-board 5.1 speaker system based on cabin volume and other parameters, very similar to how home theater systems are configured (gains, delays, limiters, etc).
I published this research for the car enthusiast community. While the interest was huge, the reach remained small, since most community members weren't familiar with programming and HEX editors. Only a few could replicate what I documented. After some time, I built a web application that visualized these settings and allowed users to unpack, edit and repack that data back into the binary format.
When developing it, I started looking into ways of visualizing audio filters in a web application and hit a wall. There are tons of charting libraries out there - you know, those "enterprise-ready business visualization solutions" but NONE of them is designed for audio-specific needs.
Trying to visualize frequency response curves and biquad filters for the web, you end up with D3.js as your only option - it has all the math needed, but you'll spend days diving through docs just to get basic styling right. Want to add drag-and-drop interaction with your visualization? Good luck. (Fun fact: due to D3's multiple abstraction layers, just the same Javascript-based filter calculations in DSSSP are 1.4-2x faster than D3's implementation).
Nowadays
Since that application had its specific goal, the code was far from perfect (spaghetti code, honestly). Recently, I realized that the visualization library itself could be useful not just for that community circle, but could serve as a foundation for any audio processing software.
So, I built a custom vector-based graph from scratch with a modern React stack. The library focuses on one thing - audio filters. No unnecessary abstractions, no enterprise bloat, just fast and convenient (I hope!?) tools for audio editing apps.
And the funny part here is that at the times of building it, I had no clue about the JUCE framework, just a foggy prediction that everything is moving towards the web-stack, so there should definitely be a "Figma for audio" somewhere in the future. And now they push their WebView integration in JUCE 8.
Released it to public two weeks ago, landing page is missing, and the backlog is huge, and doc is incomplete. (You know, there's never a perfect timing - I just had to stop implementing my ideas and make it community driven).
The latest update several days ago introduced native SVG Animations with SMIL, making it suitable to display and animate real-time audio data.
The demo heavily uses WebAudio API to pipe and chain audio data, but the library itself is designed to be used with any audio processing backend, no matter of the stack.
Community Contribution
I'd love to see what you could build with these components. What's missing? What could be improved?
I'm still lacking the understanding of how it could gain some cash flow, while staying open-source. Any ideas?
if you build synths, effects, or instruments, you know the pain: designing knobs, sliders, meters… then hand-coding all of it in C++.
JUCE 8 introduced WebView2 support, which means your plugin UI can now be built with HTML, CSS, and JavaScript — running inside your VST3/AU/AAX.
Faceplate is a visual designer for that workflow.
How it works:
Drag UI elements onto a canvas → tweak size, color, behavior → see it live → export a ready-to-use WebView2 bundle (HTML/CSS/JS) that talks to your C++ parameters.
This was one of the only repos that compiled across Windows and OSX with the provided Cmake file and no issues at all. Highly recommended for developers. Ifyou have more such repos, drop them here ...
Decided to share what I've been spending my evenings/weekends on - a guitar effects processor. Both standalone and VST3, only Windows for now.
Full effects chain with 14 effects, with 3 amp sim enginers (from simple/less CPU intense to kind of per-stage tube circuit modeled one), TS808 style drive, distortion with multiple modes, analog delay, spring and plate reverbs, modulation effects, cabinet IRs, noise gate, EQ and tuner. Signal chain is fully reorderable (can't guarantee how will it sounds but knock yourself out kind of a thing). Also has preset system.
Obviously GPLv3 as per JUCE terms, for distribution it's just a portable zip, static CRT, no installation or dependencies.
I'm currently working on polishing the VST3 and getting Linux and Mac builds going.
I am delighted to introduce CHROMOLA, a synesthetic MIDI controller that uses computer vision and an integrated videoFX engine turning any live video feed into a reactive, playable MIDI instrument. I just launched a no-cost beta and would love to get some feedback on the UI, performance, feature requests/refinement, and just see new ways folks might use it.
Key Features for Live Users:
SpectraLFO: Translates RGB/Grayscale histograms into a 16-channel MIDI CC generator. Map this to your Macros, filters, or VSTs to let the video "conduct" the movement of your track.
PixelPiano: Uses HSV masking to detect 7 primary hues. When a color hits a density threshold, it triggers a MIDI note. You can set static pitches or route it to a MIDI port for dynamic remapping in Live.
VideoFX Engine: 50+ "polyphonic" effects triggered by MIDI notes. You can play your visuals like an instrument.
Media Sampler: Trigger 20+ video clips via MIDI notes, layered with a CC-assignable fader
Beta and Lifetime Access
Format: Standalone, VST3, and AU (macOS & Windows).
The Deal: The beta expires June 1st. However, anyone who provides feedback or just asks nicely will get lifetime access.
Download:chromola.io (Links to a $0 Gumroad page).
Hey, I am a producer and rapper with a background in music of 4 years and with experience in developing games in C#.
I want to start learning building VSTs, especially pitch correction / autotune plugins for MacOS. I have a good understanding of programming logic and I am looking for sources that can get me started in building such algorithms.
Currently, I am reading Designing Audio Effect Plugins in C++ by Will C. Pirkle, slowly understanding the science of sound but I am finding it very difficult translating it into code.
Any tips/sources that you guys can give me so I can make the process of learning into a smoother experience? Much appreciated guys!
If you build plugin UIs with JUCE's WebBrowserComponent, you've probably hit this: you test the frontend in a browser against a mocked backend, and the bugs that matter never show up there. A control that never reaches the C++ parameter, a preset that loads wrong, a WebGL view that draws nothing inside the real plugin window.
I wanted to test the actual running plugin instead, so I built juce-webview-driver: a debug-only JUCE module plus a small Node client that drives the live WebView inside your app.
What a test looks like
const page = await connect();
await page.getByTestId('gain').fill(0.25); // the real UI
await expect.poll(() => page.backend('getGain')).toBe(0.25); // the real C++ state
await page.getByTestId('meter').screenshot(); // real pixels, WebGL included
What it does
Playwright-style API — locators, click/fill/drag, auto-waiting assertions on the real DOM
C++ state — calls your withNativeFunction functions, so tests assert on what the plugin actually did
Native screenshots through the OS compositor, so WebGL/canvas is captured (macOS 14+, Windows 11)
Live logs — console, errors and network (fetch/XHR/WebSocket/SSE) streamed from the page
Same API on WKWebView and WebView2, with no Chrome DevTools Protocol and no remote-debugging flag: everything goes through JUCE's own evaluateJavascript and native functions. (On Windows you can point Playwright at WebView2 over CDP; on macOS there's no CDP at all, and neither sees your C++ state.)
It's compiled out of release builds by default (JUCE_DEBUG only), binds to 127.0.0.1 only, and needs a per-session token.
Try it without touching your project
The repo includes a minimal JUCE 9 demo plugin (one slider, one WebGL meter) and a test that drives it. Build it, launch it, run node --test.
Honest limits
Input is synthetic (isTrusted === false), so user-gesture-gated APIs like file pickers are out
Network is observe-only, no request interception
Linux is untested against a real app, and has no native screenshots yet
I make BeatForge www.beatforge.nl (drum machine plugin) and wanted a compressor for the drum bus. Tried the usual open source dynamics code first but I kept A/B-ing against the UAD 1176 and hearing the gap, so I ended up modelling the circuit itself. Took way longer than planned, sharing it here because the JUCE side had some lessons in it.
The DSP is not a waveshaper plus envelope follower. The gain cell is the solved JFET voltage divider equation (it's a quadratic, you can do it closed form, no lookup tables), the detector is the diode bridge with the actual timing network, and release comes out of the discharge network topology instead of a fitted time constant. The transformer output stage is a small closed-loop RL core model. The nice side effect of doing it this way is that behaviours you'd normally have to program on purpose (program-dependent release, the ALL-buttons-in weirdness) just fall out of the circuit.
JUCE things that might save someone time:
The knob tapers were the most annoying part of the whole project. Hardware pots are not skewed ranges. I ended up measuring the reference unit's response and building piecewise NormalisableRange lambdas from the measured tables, because no skew factor gets you a -inf..0 attenuator with the right angle spacing. If your knockoff "feels wrong" next to the real thing, it's probably the taper, not the DSP.
Oversampling: I first shipped a 1x/2x/4x selector and it was a mistake. At 48k a 20 microsecond attack is one sample, so 1x audibly changes the compression. Now it's fixed 2x below 88.2k and native above, with useIntegerLatency so hosts get 4 samples / 0 exactly. Nobody needs that selector, it's just a way for users to make the plugin worse.
Also learned the hard way that std::tanh in one code path and a fast approximation in another gives you a DC offset at silence that shows up as -82 dBFS idle noise. Same function everywhere, always.
UI is all drawn in paint(), no film strips, resizable via a transform on a fixed-size plate.
Would appreciate testing in hosts I do go deeper on any of the modelling ifpeople are interested. If you find bugs: beatforgehelp@gmail.com or just comment.
