From the README:

arbor

For the future of plugin development

Goals

• Dead-simple plugin development. Write <= 100 lines of code and have a runnable blank-slate plugin.

• Ideally only require Zig as a toolchain dependency, not as a programming language. You should be able to write plugins in C/C++/whatever and easily link that code to Arbor via a C API and the Zig build system.

  • Could also have a get_zig.sh that will download latest stable Zig if you don’t already have it

• Easy cross-compilation. Compile to Mac/Linux/Windows from Mac/Linux/Windows, batteries included.

• Cross-platform graphics. A simple software renderer (like Olivec), but also native graphics programming, potentially using something like sokol, or making a thin wrapper around Direct2D/CoreGraphics for cross-platform graphics abstraction, giving the programmer a simple choice with little-to-no platform-specific considerations.

• Simple, declarative UI design. Possibly with the option of using a custom CSS-like syntax (or Ziggy) to declare, arrange, and style UI widgets at runtime or compile-time, all compiling to native code–not running in some god-forsaken web browser embedded in a plugin UI 🤮

Have:

• A nice abstraction layer over plugin APIs which should lend itself nicely to extending support to other APIs

• Easy comptime parameter generation

• Basic CLAP audio plugin supporting different types of parameters, sample-accurate automation

• A janky VST2 implementation that works in Reaper and mostly works in other DAWs

• Simple, portable software rendering using Olivec and a custom text rendering function with a bitmap font