SA_Toolkit

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

Hi Tor Helge !
Your work looks awesome to me... as far as I understand it...

As a mixer/musician with theoretical DSP knowledge, been dreaming of creating my own plugs for many, many years, tried several times without much success... the hard part for me is the software dev stuff. I'm familiar with Matlab-style DSP code and with processing arrays of numbers in C... these days getting familiar with the vst3sdk. But these strange things called "API" "SDK" "IDE" are SCARY to me (I'm on Windows). Having more than 4 or 5 source files is SCARY. "CMakelists" are SCARY. I don't like the vstgui wysiwyg editor either (+ it crashes my DAW...)
Recently managed to get Juce compiling successfully, but it's so over-sophisticated (and the basic licence gets you with a splashscreen^^).
I've really enjoyed prototyping with scripts (Cockos' JSFX reascript and BlueCat' plug'n'script), but I was so frustrated not to be able to control things like CPU optimization and custom GUI.
I think the main advantage of creating its own plugs has little to do with DSP quality/innovation, there's so much available already. It's about ergonomics. As a geeky control freak mix engineer working on a cheap laptop, my main concerns are CPU load, the dozens of large open windows in my DAW, the thousands of knobs I don't use... I'd love to clean my desktop and optimize my workflow, to finally feel in comfortable control of things and focus on mixing. One-knob small GUI window, precise custom mapping of parameter values, minimal visual informative feedback for user... things like that. These could be my "super-presets". So I need total control AND simplicity, even if it means limitations design-wise.

I'm yet getting more and more familiar with the framework, (processor/editor, buses, buffer, channels, parameter handling between proc side and editor side...), so I feel almost there. But the GUI stuff is hard. Between NoGUI (DAW's default one) and that vst3 wysiwyg editor, I can't find the middle world that would be a line of code to create some basic rectangular window, and another to add a knob with a couple of vector graphics, and why not an xml file for colors and stuff... At this stage, I don't know how to code the createView() method without using the vstguieditor, since I found no other function returning the required IPlugView type...
I'm sure I could find the perfect GUI lib for me somewhere, but since I'm lost in my IDE, I don't even know how to add a lib... all I can do is edit source files which filename contains "myplugin", from an auto-generated visual studio solution, and click on "build".

I just found your toolkit, feels like it could be a lead for me.
Gave it a shot by cloning your repos in visual studio... no "build" button appears haha : stuck ^^.
I know I could just learn the basics of software engineering. But though I love learning about how maths with digital samples turn into auditive sensations and emotions, Im very not excited by compilation, dependencies, platform/format handling, and all.

Could you tell me if the SA_Toolkit is appropriate in my situation ? Would I manage to turn it into a visual studio solution with not much struggle ?

Anyway congrats for the huge work !
(BTW couldn't find any cringeness nor pathos in your video ^^)

Post

it needs gcc/clang, and the build system is a single compile shell/bash script , so i don't think it will work, unfortunately.. at least not 'out of the box'.. you would have to do some hacking and trying, i guess..

it works with mingw on linux, to compile windows binaries, so maybe there's some inverse of that for windows? also, recently someone made it compile on clang for mac/arm.. does clang exist on windows?

sorry i can't be of much more help..

it doesn't use any build system, as there's just one single .cpp file to compile, and (almost) no external libraries to link in..
to make it more compatible with visual studiuo (or to compile from the windows side) would need someone else to step in and help..

but if you have plugin ideas, and the math/code, but lacks the plugin itself around it, maybe i could help with that..
(our discord might be a better place for that, maybe)

Post

tor.helge.skei wrote: Fri Jun 21, 2024 11:31 am it needs gcc/clang, and the build system is a single compile shell/bash script , so i don't think it will work, unfortunately.. at least not 'out of the box'.. you would have to do some hacking and trying, i guess..

it works with mingw on linux, to compile windows binaries, so maybe there's some inverse of that for windows? also, recently someone made it compile on clang for mac/arm.. does clang exist on windows?
Clang works perfectly fine on Windows (that's what I've been using for years now), can use MSVC/WinSDK headers, can use either MSVC link.exe or LLVM linker for linking and even includes a "clang-cl" driver that provides a front-end with MSVC-compatible command line parameters (with the regular unix-style use -gcodeview to generate a PDB for Windows debuggers), so you can use clang even from inside Visual Studio if you feel like it.

Mingw-GCC is also fine, but I don't know if there's any real advantage over clang, since clang does support GCC extensions even on Windows just fine. If you want bash, then install the MSYS2 stuff, that's mingw implementations of the usual unix build tools... although unless the build script does something wonky (ie. beyond "just compile everything, perhaps with a few defines"), it might be easier to just use some native build system (ie. for source with no special requirements "drag everything into an MSVC project" is a tried an true method) or perhaps CMake, which is actually much less scary than it might appear at first. For the most part, you describe the project in CMakeLists.txt, run CMake and it'll generate native build files for whatever build system you want (eg. it can generate MSVC projects for just about any version among other things, although MSVC these days also supports CMake directly I think).
Last edited by mystran on Fri Jun 21, 2024 6:48 pm, edited 1 time in total.

Post

mystran wrote: Fri Jun 21, 2024 12:28 pm...
thanks for the info!
if clang is available on windows, that would be ideal.
for compile script, there could just be a separate compile.bat, calling clang
(and similar for mac, i guess)
then we wouldn't need much else..
i like the thought of that :-)

Post

tor.helge.skei wrote: Fri Jun 21, 2024 3:22 pm
mystran wrote: Fri Jun 21, 2024 12:28 pm...
thanks for the info!
if clang is available on windows, that would be ideal.
for compile script, there could just be a separate compile.bat, calling clang
(and similar for mac, i guess)
then we wouldn't need much else..
i like the thought of that :-)
You can use a single script for Linux/macOS if you capture `uname` and branch on "Darwin" for macOS specifics.

It's also possible to detect Windows by checking if the value of $OS environment variable is "Windows_NT" (which is what I do with my GNU Makefiles for autodetecting the OS), but obviously for shell scripts you'd then need the user to install bash which is less than ideal, not that requiring GNU Make is better.. but I just like using it anyway, 'cos I can have it auto-detect source-files without having to touch CMakeLists.txt .. which honestly is (together with the incredibly spammy build output) the only thing that I don't like about CMake (yet, I still use CMake for some stuff too; just easier if you're using libraries that already support it).

Looking at your source tree on github it looks like it's all headers, so incremental builds wouldn't do much... but with larger projects those are just too nice to pass.

Post

yes, it is a collection of loosely connected, small (-ish) header files/libraries.. requires a bit of planning and care, especially when touching the 'lower' parts/layers of the toolkit.. (but it does wonderful things for optimization!)..

there's some history involved.. the toolkit started 15+ years ago, as a simple header file to help someone compile their vst plugins to linux.. then it just grew and grew, bit by bit.. it's been rewritten (or refactored, reorganized) several times, and been through a couple of language changes (c -> c++ -> object pascal -> "orthodox c++"-ish).. and now, after so many years, it has been massaged and tweaked, ad absurdum, everything has become muscle memory, and i can code _very_ rapidly, almost on autopilot.. it works unexpectedly well.. at least for me..

since it's just one single .cpp file to compile, a build system is not really needed, in my opinion.. one less dependency, one less layer where things can go wrong.. very few libraries to link in (just a few system libs, plus x11 and opengl for linux), and a couple of macro definitions.. one .cpp file, one compiler invocation..

i like low-level, stripped down things.. :-)

i have nothing against adding makefiles (cmake or whatever), if it doesn't interfere (too much) with how i code.. i wouldn't use it myself, probably, but if it could make it easier for other people, it would be nice.. (maybe i would 'see the light' too, hehe)

"Within C++, there is a much smaller and clearer language struggling to get out."
- Bjarne Stroustrup (The Design and Evolution of C++)

Post

tor.helge.skei wrote: Sat Jun 22, 2024 1:10 am i like low-level, stripped down things.. :-)
I guess its what caught my eye. Makes it highly readable at first look, without much abstraction layers. I'm definitely gonna try to compile this thing, its worth learning a bit about compiling with clang. Thanks for the huge info.
1 more question (hope its the right place for noob things, first time on the forum) :
Which one is the main source file to be compiled ? Is there some "main" function including everything else ?

Post

rsoulard wrote: Sat Jun 22, 2024 2:18 am I'm definitely gonna try to compile this thing, its worth learning a bit about compiling with clang. Thanks for the huge info.
1 more question (hope its the right place for noob things, first time on the forum) :
Which one is the main source file to be compiled ? Is there some "main" function including everything else ?
cool!
there's no main .cpp file for the toolkit, only one for your plugin itself, for example:
https://github.com/skei/SA_Toolkit/blob ... est/gain.h
which i was going through during one of the previous videos i posted..
(there's reasons for this being a .h file too, the compiler doesn't care)

Post

i usually type "./build/compile -i ../build/build.cpp -o plugin.clap -f clap -g x11 -d"
inside the /bin directory, and a finished .clap binary pops up there after a couple of seconds..
if i have my daws pointing to this directory, and it automatically rescans new plugins,
it takes max 5-6 seconds from pressing enter, to having the plugin running inside for example bitwig..

Post

tor.helge.skei wrote: Sat Jun 22, 2024 1:10 am i have nothing against adding makefiles (cmake or whatever), if it doesn't interfere (too much) with how i code.. i wouldn't use it myself, probably, but if it could make it easier for other people, it would be nice.. (maybe i would 'see the light' too, hehe)
I feel you.

I like to use this sort of Makefile for similar "don't interfere with me" reasons: https://github.com/signaldust/dust-tool ... kefile#L94

That thing automatically finds all .c/.cpp files inside 'dust/' and it's subdirectories and compiles each, then builds a static library out of those. Then it turns each subdirectory of 'programs/' or 'plugins/' into it's own build target with all the .cpp files inside included in that target. I tend to use similar Makefiles for other projects, though the details obviously vary a bit.

So essentially I'm using the filesystem as a build-configuration directory and adding/renaming/removing files or even additional binary targets just requires putting the source files in the right place and it'll automatically work without even touching the Makefile. All I have to do is edit files and type 'make' and if something ever goes wrong 'make clean' deletes the whole 'build/' directory where it dumps all the build artifacts.

Yet the true beauty of this setup is that even though it's "put files here and they get compiled" .. it still tracks dependencies automatically for incremental builds: when compiling something it passes '-MMD' to the compiler to also generate a dependency list and then next time when it's finding the list of files, it'll check if there's a matching dependency file and include that if so.

Post

interesting! that sounds like a setup i could work with.. the question about building and makefiles and stuff has come up more often lately, so i should probably just bite the bullet and look more into that.. i will have a deeper look at it a little later, and maybe 'steal' an idea or two from you.. :hihi:

Post

More GUI mumbling..
https://www.youtube.com/watch?v=bbANuZu4pJo
(youtube processing hd version very slowly, says 23 minutes left)

extensions/_compat, widget hints/help, multi-param widgets, tweening/animation, gui overlays, param indication, ...
plus a little bit about upcoming things..

Post

no video this time, but still a bunch of stuff happening..

improvements/work on: resizable/movable widgets, main menu widget, widget (layout) stacking, tweening/animation, overlays, widget hints/help, multi-parameter widgets, parameter automation/modulation indication, remote controls, ext/_compat, (multi-threaded) voice processor, more debugging and (initial) logging and unit testing things, vst2 & vst3 wrappers, win32 gui.. and a bunch of other smaller things here and there.. as well as a bunch of ported, and other plugins brought over from v1 to v2.. (and if you dive deeply, you might find some initial mac support things lurking in there too)..

i will focus on linux, and will probbaly only release clap plugins myself.. but if somebody want to help with fixing and keeping the windows version up to date, or get the mac version into shape, or improve the wrappers, or anything else that would make the toolkit (more) useful for people.. we would be extremely happy! :-)

Post

i impulsively decided to do a 5-minutes or so "what's happened since last time" video, but it resulted in an hour.. typical.. :-)

the first 20 minutes is mainly about the new gui things, then 25 minutes of synth stuff and clap extensions, before the final fifteen minutes about windows version, vst3, and the debug window and observers.. raw and unedited, as usual..

https://www.youtube.com/watch?v=CwyeszD_OOk

Return to “DSP and Plugin Development”