Hacker News new | ask | show | jobs
by julesrms 1969 days ago
Full support for wide streams (i.e. streams of overlapping windowed blocks, suitable for frequency-domain work) is still to-do (though we've planned for it all along!)

We've tried to make embedding it as easy as possible - there's a DLL, and a simple COM interface and a few header-only C++ classes to load and JIT-compile a patch dynamically. We have an example project showing how to do this. FWIW Tracktion Waveform is doing exactly this, and only has a few hundred lines of glue code to enable patches in a full-blown DAW.

1 comments

Good to hear! I'll stay in C/C++ until its ready then - I look forward to not needing to prototype in one language and implement in another, but for now the biggest motivator is how easy it is to do spectral/cepstral things in MATLAB (bit of a pain to write windowing code in C++, hard to test, and easy to get wrong).

Why COM (and is it actually COM, or is it COM-inspired like VST3)? It's a bit of a pain to interface with it from hosting languages (C is much more straightforward, particularly when worrying about C++ exception safety and garbage collection).

Why COM? Well, I hate COM in general, but it was a much better fit for this particular API than flat C functions. It comes with a bunch of C++ helper classes to make it easy to work with, and the resulting code actually ends up looking OK.
It seems odd to spend a bunch of time working on a C++ alternative for audio DSP but to rely on one of the most annoying C++ paradigms to deal with to embed it in anything useful. I don't really care how the library code looks (if the secret sauce is proprietary and closed source anyway, that presents zero value to me as a potential licensing customer!), I care how it functions.

I want to script together many soul patches into a complex systems written in higher level languages. Integrating C++ dependencies is avoided because of the headache of FFI, C is quite straightforward. I suspect users like myself will need to wrap your COM API in its C-equivalent through manually written vtables regardless, which is its own minefield rather than a proper API.

I hope it doesn't require the COM runtime...

COM is relatively common and accepted in audio (VST3 / AAX). Usually it doesn't require the COM runtime from Win32, it's just an ABI for being able to virtually call and delete shared objects.
All modern Windows APIs since Vista are based on COM, so it isn't going away anytime soon.

As does macOS/iOS driver model.