Sapphire for the DAW in beta test

Lounge
1

Paul (@baconpaul) and I are pleased to release an open source DAW plugin using four of my Sapphire modules.

This project takes Elastika, Tube Unit, Gravy and Galaxy from Sapphire and makes them available as a stereo/in-out clap, vst3 and auv2 plugin for you to use in Bitwig, Logic, Reaper, Ableton Live and so forth.

Rather than the CV/attenuverter path, we’ve made each of the VCV parameters exposed as automatable parameters in your DAW. To make them DAW-friendly, we have added a MIX control to Tube Unit and Elastika. Therefore, all four included modules have MIX knobs. We also shifted the panels to remove unneeded controls like ports and attenuverters.

You can grab the plugin here:

Currently we have a few things left to sort out so haven’t tagged a stable yet, but the nightly works great. We would love your feedback.

  • Elastika is good for creating stereo-field percussive sounds, gongs, and some drones. See Omri’s video below, demoing Elastika as a metallic drum.
  • Tube Unit is a tubular waveguide simulation that makes highly modulatable drone sounds. It’s fun to feed into either of the next two modules!
  • Galaxy is a port of Chris Johnson’s Airwindows Galactic reverb algorithm in a Sapphire-style panel. This reverb is amazing for creating chorus and wide stereo field.
  • Gravy is a stereo state-variable filter as described in a paper by @andy-cytomic . See page 6 of that paper for the equations used in Gravy.

We are eager to hear back from anyone who tries these out. Questions and comments welcome.

Thanks! Don and Paul

27 Likes
2

Cool!

Too bad the cmake requirements are too new for my systems and the current builds are using a way too new libc to run as is.

While “bleeding edge” is really cool and all, it’s also not very realistic when publishing binaries meant for the rest of the world :#

(seems that the cmake requirement is because of some feature in the clap wrapper)

[edit: ok I thought I already had cmake from debian backports, now I really have it and can build locally :slight_smile: ]

1 Like
3

Hmmm, even though the project uses JUCE it seems that it doesn’t build a JUCE plugin?

I guess it uses some odd hacks to first create a clap plugin and then build the VST3 and AUV2 from those instead of the “normal” methods in JUCE?

Too bad since I was going to try adding LV2, but that totally breaks here.

4

Nice! Looking forward to running absolutely everything through tube unit :joy:.

3 Likes
5

Yes, the cmake package was too old for me also on my Debian system. However, it is very easy to build from source. For VCV plugin development, I ended up building g++, cmake, python3, and other tools from source to compensate for Debian package lag.

I’m strongly considering upgrading my Linux development box to Debian Testing so I can have something closer to a rolling release. I’m also considering Arch, but that might require me to learn too much stuff just to get back to where I am now, productivity-wise. It’s on my bucket list though.

I’ll step aside and let @baconpaul answer these questions, as I’m too new to the DAW world.

6

The binary we distribute is made in a ubuntu 20 container. The software is buildable by people who dont meet the constraints of that five year old choice set. Here’s the exact docker file we use. sst-dockerimages/ubuntu20-gcc11-cmake328/Dockerfile at main · surge-synthesizer/sst-dockerimages · GitHub

It is not a juce plugin, that’s right. It uses JUCE for the ui. It uses the clap wrapper technology to expose a clap as a vst3, auv2, etc…

7

Thanks for all the feedback already! We’ve fixed a few things people found and finished a few more so if you did an eager upload as soon as you saw this, a refresh is a good idea!

8

Here’s a test I made using these:

2 Likes
9

Very nice! Which DAW did you use?

10

Thanks Don, I was using the plugins inside Reason.

11

Awesome… it’s nice to know people are testing in multiple DAWs. I have been using Bitwig Studio on Debian Linux x64. We’ll be interested to know any other results for these or other DAWs, especially any issues you encounter.

@baconpaul has been amazing at boost-launching my entry into this new world of writing DAW plugins. I might post something on the development category later about what I have learned so far, in terms of what is different in DAW plugin development compared to what you do when you are accustomed to VCV Rack plugin development.

2 Likes
12

I usually test in bitwig reaper and logic at least before I ship something and often in live and fl too. The wrapper has also been tested in Cubase pretty extensively. Definitely interested in daw specific bug reports though. Both this project and six sines are sort of stealth ways to test the wrapper in a broader setting.

13

As I said I get a number of tools from back-ports, which should be a lot more stable than testing (which has a tendency to sometimes inexplicably break … like any rolling release and is imo harder to use around the next stable release time). Just somehow my cmake wasn’t up to date on this particular machine (and I thought it was). My current version of cmake is 3.31.4 which tracks their current stable release.

Ah I see the change to a nested docker setup in the CI a couple days ago. Only noticed the ubuntu-latest before that, but it seems that the Matrix build in the CI still uses that?

We only see one Linux build in the Nightly uploads, which would be the one from the Matrix build, no?

14

I was wondering about the stability risk. Perhaps the way I do things isn’t so bad after all: use stable release but manually build the development tools that aren’t fresh enough in Debian packages.

15

No the binary is from the docker build

Ci does both (to make sure we can build with latest and old) and uploads the docker one

You can read the entire action in the .GitHub/workflows

And yeah if you looked at workflows pre announce or thereabouts it was matrix build but I moved everything to docker in baconpaul over the last fortnight (we had moved surge last year but Id kept the docker image constrained to surge projects so I fixed that and then used it here. Airwin was the first to get canaried out by the move to u24). Binary distribution is by far the worst part of Linux life but seems u20 + gcc11 is a reasonable baseline

16

Aah I see so that’s why the matrix is still there. Check.

Yeah I currently use 20.04 for everything as well and that seems to cover most libc requirements. In a couple years we can move that up to 22.04 or whatever.

VCV Rack still has 16.04 in all the docs (although I haven’t confirmed that all their toolchains actually use that).

17

The rack toolchain is different

They use u22 or 24 but then hand build a libc and libc++ and compiler. This is why their docker file takes hours rather than minutes to assemble. But it gives you modern tooling with antique runtimes

The problem of course is that high gcc will compile c++20 but not the bits in libc++. This is same reason that if you target macOS 10.13 you get some features from c++17 missing (since the os predates the standard freeze). Apple makes this way easier than the Linux-initiated-operating-configurations people run but it’s still real

The strategy we’ve generally taken in surge land is

  • target macos 10.13 or 14, build and sign with modern Xcode
  • Linux target u20 gcc11 and Use docker files and compile flags to get there
  • Windows statically link the runtime

And that works but since rack requires macos 10.9 we may end up stuck with new surge which has a dependency requiring 11. And similarly short circuit requires 10.13. I know the rack team is thinking about this (one reason I know that is because I bug them)

All our docker files and GitHub actions to assemble stage and use them are liberally licensed open source. Happy to share

1 Like