5 ms·

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

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.

hctaw 6y ago
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).
- julesrms 6y ago
  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.
  - hctaw 6y ago
    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...
    - p0nce 6y ago
      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.
    - pjmlp 6y ago
      All modern Windows APIs since Vista are based on COM, so it isn't going away anytime soon. As does macOS/iOS driver model.

hctaw 6y ago

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).

julesrms 6y ago
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.
- hctaw 6y ago
  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...
  - p0nce 6y ago
    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.
  - pjmlp 6y ago
    All modern Windows APIs since Vista are based on COM, so it isn't going away anytime soon. As does macOS/iOS driver model.