It's totally fair to criticise it for being a horrible, ugly technique. But in terms of fragility, it's no worse than bundling the same DLL as a file along with your app.
(In fact, it's less fragile than a loose DLL, because you don't run the risk of your DLL failing to install/being moved/accidentally loading some other random version of the same DLL etc)
In case you're not just riffing: no, it's not statically linked.
The WebViewLoader.dll is embedded in the source code and then loaded into memory as if it was loaded via LoadLibrary() or by Windows .exe loader which loads referenced .dll automatically.
Granted, he re-implemented LoadLibrary() to load from memory, which can potentially break if Microsoft changes the details of how LoadLibrary() is implemented.
This is one of my pet peeves with Microsoft API design. LoadLibrary() only works with files from disk.
It should be implemented as a trivial wrapper around LoadLibraryFromMemory() but Microsoft didn't implement LoadLibraryFromMemory so we have to resort to re-implementing LoadLibrary when we want this very useful functionality.
I wrote this a year or two ago and have forgotten the details, but there was definitely some reason why you couldn't "just statically link" it, otherwise that's exactly what I would have done, and saved myself some hassle.
IIRC it was either because there wasn't support for it back then, or the static version didn't support older Windows versions, or somesuch Microsoft nonsense.
But for whatever reason it was, they strongly push people to use the DLL, and deploying DLLs in installers is a PITA, so...
That's about when they added the capability, yeah. They've dropped support for win 7/8, not sure if CHOC goes back that far.
I suppose this would break the "Nothing needs adding to your build system to use any of this stuff.", but that doesn't seem true now that Boost is a dependency for the server stuff.
The use-case for SOUL is about as far from a "glue" language as you can get!
It's a language for writing the absolute lowest-level, close-to-the-metal, bit-twiddling realtime code which you'd then glue together using a higher-level language like C++, javascript, python, lua, etc.
Well, as the person who also created JUCE and its license, I can't really argue with that. :)
We're very keen to make sure that the end-user developers are totally unencumbered and license-free, because we want lots of people to adopt it.
All our licensing is more aimed at device and driver builders - think of it like e.g. openGL - the industry making GL cards and drivers is legal complex, but none of that stuff affects the coders writing GL apps.
The license is pretty clear, you can do anything you like with the language and the software that has been open sourced. If you want to write your own renderer, that's great! If you want to write a decent interpreter, or a rubbish one for that matter, again, that's great, that's your business.
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.
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.
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.
The patch format is for the same use-case as VST, AudioUnit etc, where OSC isn't really a thing.
OSC is more something you'd want to use for a stand-alone program, which needn't be written as a patch. But yes, would be nice to add some OSC wrappers one day. Maybe it's the kind of thing that someone else will contribute before we get around to it.
- end-user developers. This is kind of like being a user of any other language, there's no EULA, nothing to sign, you just write SOUL code, test and debug it with whatever tools (which may themselves have a EULA, but probably nothing heavy)
- device and host developers: These are the people writing DAWs, plugins, hardware that can run SOUL code, audio device drivers etc. These are professionals, and licensing is a normal part of life when you're doing this kind of work.
sigh... The JIT engine in your graphics driver stack will contain millions of lines of heavily-licensed, patent-riddled code.
But that doesn't stop you as a developer from freely writing a 3D game that runs on it.
Same here. Think of it as a device driver. Ideally we'll open-source everything eventually, but anyone who's ever been involved in real-world commercial software development will understand that things aren't always quite that idyllic when you're building a business around it.
Real answer: Mainly the JIT engine, and the very complex rewriting algorithms that turn multi-threaded soul code into a form that can actually be executed.
We're certainly keen to open-source everything when possible, just been advised by our lawyers not to do that yet. C'est la vie.
Yes - the command-line tool will take a SOUL patch and emit a full, ready-to-build JUCE project that will create all the plugin formats (and a standalone app).
* is header-only
* supports EDGE on Windows without the need to have the WebView2 SDK or to bundle a runtime DLL
* supports fetch intercepting and some other customisation
* is modern C++ rather than a sort of mashup of C/C++
then check out the one in the CHOC library here: https://github.com/Tracktion/choc/blob/main/gui/choc_WebView...