ROADMAP

Where semitone is going

APRIL/MAY 2026 — v0.1

Interpreter core

NOW
  • double, float, int8–int64, uint8–uint64
  • bool, char (ASCII)
  • Matrices
  • Cell arrays and structs
  • for loops, if / else
  • Full trig, exp/log, rounding, type conversion
  • Chunked scalar execution mode with duplicate subexpression detection
  • num2str, disp, struct, cell
  • ~200 kB pure C++17, no dependencies

MEDIUM TERM — v0.3

Built-in DSP components & further integration

PLANNED
  • Built-in DSP primitives/components: filters, etc.
  • JUCE integration helpers
  • Live Coding tool (web/standalone app)
  • Expanded chunked scalar mode
  • parfor loops
  • Complete Doxygen documentation

LATER — v1.0

Transpiler

FUTURE
  • C++ code generation (transpiler) — major project
  • Generated code competitive with hand-written C++
FAQ

Frequently asked questions

Why not use Julia?

Julia is a reasonable choice for scientific computing but it's not something you drop inside a VST plugin. The goal is an interpreter small enough to embed in real-time audio software — ~200 kB, no runtime, no GC pauses, no external dependencies.

Why not use Python + NumPy?

After writing np. for the thousandth time, and debugging trailing commas created tuples that weird stuff far from where the error occured, the friction becomes obvious. Octave's syntax is better suited for expressing DSP algorithms.

Why not make a C library?

Because the goal is to write and run code directly in a real-time environment — not just at compile time. A C library gives you fast components but not a scriptable layer that a DSP engineer can modify without recompiling the host. However, eventually semitone will come with its own builtin DSP components and once transpilation works, you'll get the best of both worlds.

Will semitone ever generate C++ code?

Yes, that's a long-term goal. The ideas on how to transpile from semitone to C/C++ are there. But it's a substantial project on its own and will come after the interpreter is stable and open-sourced.