Apologies if there’s an obvious answer to this, but I’ve looked around and haven’t found one:
Is there an example somewhere of how to call the standalone code that is generated with soul generate -cpp?
I’m just trying to run some of the example patches, and while my code compiles fine, it doesn’t seem to produce or process any audio which makes me think I’m doing something wrong. It’s probably very elementary but I’m new to SOUL and don’t really know what I’m doing!
My wrapper code (for the OWL embedded platform) looks like this:
Also, is it generally okay to pass the same buffer in the context as input and output data (in-place processing) or do I always need to make a separate output buffer to avoid clobbering the input?
The only thing that jumps out at me is that the soul class doesn’t expect the same pointers to be used for both input and output channels, so that could be causing problems. If your calling code is supplying a single buffer to act as both input and output, you’d need to wrangle it into separate channel copies like we do in the audio plugin wrapper classes.
A tip here is to run the generate --juce option on your patch, and have a look at the glue code that it generates, since it’ll be correctly calling into the same C++ class that you’re trying to use.
BTW I’d always recommend using a local context object each time you call render, not a member variable. As well as making it easier to see what’s going on, it’ll probably also perform better (though you might find that counter-intuitive)
Thanks, got that working now, I think the numFrames initialisation was a problem.
And yeah I noticed that RenderContext is passed by value, which is a bit surprising.
All in all I have to say: nice work! A near-minimum of dependencies in the generated code. And even if you use std::vector and std::array it is still possible to compile without exceptions and full -lstdc++ linkage.
Good point about the assert definition - it’s clearly a mistake that we’re generating the unguarded version, and I’ll get rid of that right away, ta for reporting!
This is working now with the v1.0.75 release, thanks!
btw I think there’s a typo in one of your examples:
examples/patches/TX/ElectroPiano/ElectroPiano.soul:15
graph ElectoPiano [[ main ]]
should be
graph ElectroPiano [[ main ]]
Though there is another graph inside the patch called ElectroPiano so maybe it is intentional, but it means the generated class ends up with an odd name.
And a feature request:
Could you add an option to CLI generate to specify the output class name? This would make it much easier to generate code with a reusable wrapper, i.e. one that is agnostic to what the main graph is called internally.
Thanks for pointing out that example - there’s usually a voice and a graph class, and the names look to have got mangled at some point. So that’s not a typo, those need to be named differently