FR: PatchPlayer additions


now after I got the basics working fine, I’d like to ask a few specific details about the PatchPlayer class. I am trying to embed SOUL into an existing polyphonic system and there are two things that would be helpful to know:

  1. What does the reset() function do on the SOUL side? Is it setting all variables back to their initial state or is there more magic involved? And is it realtime safe to call this in the audio thread? I would call this method at every voice start to reset eg. the oscillator uptime or filter coefficients, then call render until the voice is stopped (from the outside).
  2. Can a PatchPlayer be cloned without having to be recompiled if neither the input files or the playback configuration has changed? A simple PatchPlayer::clone() method would be enough. I’ve seen a clone() method in one of the more low-level classes, so maybe it’s a trivial addition. I will use a SOUL patch inside a polyphonic system that requires each voice to have their own PatchPlayer and creating 256 sine oscillators takes 20 seconds, because each voice is compiled (compiling one voice takes 76ms on my computer).

Yes, it’s safe to call reset() in the audio thread. There’s no non-realtime safe code happening, but of course if you write a processor that does very long calculations in its init function then it could take a while to execute.

What will actually happen on most back-ends is that the init code will be run the first time reset() is called, and then a snapshot of the state is taken so that subsequent resets become just a memcpy to restore it.

Cloning a patch player is something I hadn’t thought about - it’d probably be simple enough to add, but TBH what we’re really focusing on are systems where you have 256 processors in a single patch rather than 256 patch players in a native.

But cloning a patch should be pretty quick, given that almost all the work happens in the LLVM optimiser, and if you use a cache then it should only take a few ms to do the front-end compile + restore the cached object code.

A possible use case of patch player cloning is using a voice written in SOUL in an already written C++ (or whatever) polyphonic machinery, where cloning the given voice is usually the way to go. We could have this need in our Faust/SOUL hybridation model.

It’s a totally valid FR, I’ll add it to our backlog