osci-render, a synthesiser you program by drawing on an oscilloscope

The instrument model and what makes it unusual

The tagline in the repository description is the whole idea in a few words: an open source synthesiser for making music by drawing objects, text and images on an oscilloscope using audio.

The rendering is not a metaphor. The software contains a software oscilloscope, and the shape you draw on it is what generates the sound, with the vertical axis mapping to frequency and the horizontal axis to time in the way a real oscilloscope trace does. That is why the project is called osci-render and why the description says it allows for 3D rendering of .obj files, .svg images, .txt files and Blender scenes on Windows, macOS and Linux.

The relationship with Blender is the interesting one. A Blender scene can be rendered and fed into the same pipeline, so a rotating object becomes a rotating sound. The demonstration in the README is an animated Blender scene, and the project file used to create it is checked in as a .osci file, which is the project format.

The second half of the design is that it is a fully programmable synthesiser. Custom visuals, sounds and audio effects can be scripted using Lua, and the Lua script is not a side feature but the editing model, because the interface has a code editor where you edit the file and see the changes in real time, and you can edit the code while the file is playing with the changes applied immediately.

That combination is what separates this from a drawing toy. A drawing toy would let you sketch a shape and hear something. Here the shape is a program, and the program can be edited while it runs.

Everything is controllable from a digital audio workstation, allowing for parameter automation and MIDI control, and the README notes that you can also use it as a standalone application if you prefer.

The licence is GPL-3.0 for the source code, with an explicit carve-out: project names, logos and branding are not licensed under GPLv3, and the README points at a TRADEMARKS.md and at branding notices inside the image directories. That is a careful and correct way to separate the code from the name, and it is what lets the project be open source while still being sold under a name.

The feature list, from drawing to DAW automation

The current features list is short and each item is a capability rather than a checkbox.

On the rendering side there is 3D object rendering, SVG vector image rendering and text rendering, plus the Blender integration and the software oscilloscope that all of it is drawn on.

On the scripting side there are scriptable visuals and audio effects using Lua, and applying image effects with a list that includes bit crush, vertical and horizontal distortion, image wobble, image smoothing and image tracing, and the README says and more. That last phrase is worth noting, because the effect list is open-ended and the effects operate on the image, which means they operate on the signal before the audio is produced rather than as a filter after it. A wobble in the picture is a modulation in the sound.

The control side is where the integration with a production environment happens. There is MIDI control, parameter automation from a DAW, and saving and loading of projects.

The screenshots reinforce the point about the code editor being central. There is a screenshot of the main interface, one of the code editor, and one of an imported .obj file, so the three things you do are play with the oscilloscope, edit the code, and load something in.

The demonstrations in the README cover the three workflows a user would want to see. The first is an animated Blender scene rendering, with a .gif of the result. The second is applying audio effects to a Lua script, with the project file square_spiral.osci checked in. The third is automating parameters from a DAW, and the fourth is playing a MIDI keyboard while changing envelope parameters, with the Reaper project square_spiral.rpp checked in alongside it.

The Reaper and osci project files being in the repository is a small but useful detail. You can open them, hear what the author heard, and see how a DAW session is set up around the plugin, which tells you more about the integration than a paragraph of prose would.

Installing it and the free versus premium split

The download page is osci-render.com, and the README is explicit about the model. You download the free version, or purchase osci-render premium from the official website to get access to the latest version, and after purchasing you are sent an email with a download link for Windows or macOS, as a standalone application or as a VST or AU plugin.

The distinction between free and premium is worth noting because the wording says the free version and the premium version is the one that gets the latest version. In other words the current release is available for free and the paid tier tracks the most recent build. That is a common and reasonable arrangement for a project with an active development community, and it means the free tier is a real product rather than a demo.

The standalone application install is straightforward. On Windows you run osci-render.exe, on macOS the osci-render.app file, on Linux the osci-render executable, and the README notes you may need to allow the application to run if you get a warning, with a link to Apple's support page for bypassing the security warnings and the app is damaged message on macOS.

The VST3 install is a file copy. You copy osci-render.vst3 to your VST plugins folder and restart your DAW, and the README gives the usual locations, C:\Program Files\Common Files\VST3 on Windows and /Library/Audio/Plug-Ins/VST3 on macOS.

The AudioUnit install on macOS is the same shape, copying osci-render.component to /Library/Audio/Plug-Ins/Components and restarting the DAW.

One thing to notice is that the standalone and plugin installs cover Windows, macOS and Linux for the application, while the plugin instructions are given for the VST3 and AU formats, which are the two that matter on Windows and macOS. The project also advertises a Discord community, a Codacy code quality dashboard, and a direct email address for issues, feedback and feature requests.

How it fits against the alternatives

There are two comparisons to make, and they are quite different from each other.

The first is against other audio visualisers and scope toys. The closest relatives are software that draws an oscilloscope trace from incoming audio, and the difference is direction. A visualiser takes sound and draws a picture of it. osci-render takes a picture and makes sound. That inversion is the entire product, and it means the tool sits in a different place in a workflow, because the picture is the source rather than the output.

The second is against other synthesisers. A subtractive synthesiser starts with oscillators and filters and subtracts. A wavetable synthesiser starts with a table of samples. A granular synthesiser chops audio into grains. osci-render starts with geometry, which is a fourth way of thinking about a sound source, and the closest relatives are physical modelling and additive synthesis, where the timbre is defined by the shape of the waveform. In an oscilloscope synthesis, the shape of the wave is the shape of the drawing, which is a direct and legible relationship between what you see and what you hear.

The practical strengths are that it works with files you already have, since any .obj, .svg or .txt file is an input, and that the pipeline is scriptable, so a visual can be driven by parameters the way any other synthesiser would be. The Blender integration is the strongest example, because it turns an animation into an audio performance rather than a static sample.

The limitations are inherent to the model rather than to the implementation. Drawing a complex shape is more work than choosing a waveform, so the tool rewards the prepared. The mapping from picture to sound has to be learned, because the axes of the oscilloscope carry a specific meaning that is not obvious at first. And the scriptability that makes it powerful also makes it a tool you configure rather than one you play directly in front of an audience, unless you have done the preparation in advance.

The Lua angle is the thing to evaluate if you are a programmer. Custom visuals and effects written in a scripting language inside a plugin is a much bigger surface than a set of parameters, and it is the reason the code editor sits in the main interface. If scripting sounds attractive, this is a distinctive instrument. If you want a plugin you load and tweak, the depth is more than you need.

The version numbers tell you about the trajectory. The releases are v2.7.2.4 in January 2026, v2.8.9.18 in April and v2.9.9.3 in September 2026, with a fourth segment in the version suggesting a build counter rather than a semantic version, and the last push on 2026-10-17. It is a project in active development, which is a reason to try the free version and a reason to expect the plugin format and features to keep moving.

Editorial conclusion

Adopt osci-render if you make music and want to generate sound from images and shapes rather than from samples, and you are willing to write Lua to script it. Skip it if you need a conventional subtractive synthesiser, because this is a completely different instrument model. Verify first by installing the free version as a VST3 plugin, loading a simple SVG, and confirming the sound changes as you draw, before you script anything.

Frequently asked questions

Official sources

1. jameshball/osci-render on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases