Home

Awesome

Stochas

Main web site

Download

To download pre-built binaries and installations go here

Platforms and DAWs

The original product has been tested on Windows and Mac using Reaper, Logic, Cubase, Ableton, FLStudio, Studio One, Cakewalk, ProTools. The open-source version has been so far tested on Windows, Mac and Linux using Reaper, Logic, Bitwig and others, but should have no problem with other targets. By default AAX is not built, but if you have the AAX sdk you will be able to enable this.

Building

Pre-requisites

Building

VSCode

Development is a lot easier with VSCode using the CMake extension. Simply point vscode at the root directory of the repo. It pretty much detects a cmake project and handles building without any issues.

XCode

If you want to use XCode on macintosh, adjust the first cmake command to cmake -B build -GXcode and your build directory will contain xcode assets.

Projucer

Prior to JUCE v6, Stochas was managed via Projucer. With the port to v6 and also the release of Stochas as OSS, Projucer is no longer in use. There were some settings in Projucer which had to be adjusted depending on the target. These notes may not be applicable anymore. In particular channel config should be looked at... from juce cmake doc " It is recommended to avoid this option altogether, and to use the newer buses API to specify the desired plugin inputs and outputs." Following are the old notes from Projucer days:

VST and AAX

On an additional note for AAX there are linking errors on building in XCode, so the following settings have to be set.

I have read somewhere it’s associated with how Xcode built the SDK at my end, but rather than go fiddling and trying to recompile the SDK in other ways, I just stick to the above settings as they work.

AU

Notes on CI

Unlike the other things at surge-synthesizer land, because of a few oddities in AU formatting and flags, a production build of stochas requires multiple compile passes. As such, a set of scripts in scripts/{os}-build.sh assemble the final product on a per-platform basis into a directory called product/ and the actions flow in .github/workflows calls out to this, then uses the standard surge upload etc... pattern.

If you want to change a production build, you can just run the scripts on your local machine to see what they do and to adjust them.