mystran wrote:Oh, but I don't mean running scheme-code in real-time thread, rather just using it to generate native real-time code on the fly could be useful. It's not exactly hard to generate C code for offline compilation, but it gets a bit messier if you want to do it all at run-time. Also embedding anything in a plugin usually requires some constraints of resource management and such, and I was just wondering if you've investigated whether either Racket or (more interestingly) LLVM can happily exist in such an environment. I'd imagine it's probably possible, so I was simply wondering whether you'd tried.
Re-loading compiled binary from generated C code at run time is already working. My dev setup is in Pd on Linux, and I have a tiny ad-hoc binary object format that can reload processing code while leaving the internal state intact, as long as the state and parameter configuration is compatible. This allows small tweaks to the algorithm to be made with about a 2 second delay from code save to it being uploaded automatically in the running Pd test patch. This was an important point to get right!
The same could possibly be done with a VST api, but I don't have enough low-level windows or OSX experience to make that work at this time, and no particular inclination since the Linux setup works so well. Happy to assist anyone wanting to give a stab at it though
The constraints on resource management are pretty severe at this point: the internal binary object format does not allow for any external dynamic dependencies. Only static code is allowed (note: not even libc or libm!). This might sound a bit drastic but it works surprisingly well in practice when you're working on low-level code. I.e. I don't use any libm calls in my code anyway: all is done with special-purpose polynomial approximation.
As for LLVM, it is designed to make it generate LLVM code in a straightforward way. For now I am generating C because that's easier to use until the specification language stabilizes, but the C code that comes out is just LLVM-style single assignment.
What I'm thinking is that the internal plugin format could probably be separated out into a separate project. It might be useful as an internal test tool in other projects, without exposing the binary interface. Such a thing can be kept simple if there is no requirement for backward compatibility.