Maintain script state over hot-reload?

[capital-G]

Currently we reset the EEL2 VM if a script gets reloaded, which also resets its state.
Yet I think it could be possible to continue with the current state of the script - yet there should probably also a way to reset the state in this case?

[Spacechild1]

I think there could be a UGen argument that controls whether the code should update or persist. The plugin cmd can then check a bool in each Unit to know if it should be updated.

Alternatively, if this argument is init rate and false, the Unit simply won't register itself. However, I think control rate would be better because then you can temporarily "freeze" or "unfreeze" a particular Unit at runtime.

[capital-G]

I think there could be a UGen argument that controls whether the code should update or persist. The plugin cmd can then check a bool in each Unit to know if it should be updated.

This would actually be an additional feature than the one I was referring to.
It is possible to replace the script of the EEL2 VM w/o resetting its state, such that accumulators/phases etc do not reset while live coding which could interesting but also result in lots of problems b/c of tainted state. Yet I think this could be up for the user to decide and simply provide sensible defaults which would be to reset the state of the machine on a code change.

So probably something like (?)

DynGen : MetaDynGen {
	*ar {|numOutputs, script, inputArray, updateScript=1.0, keepState=0.0|

[Spacechild1]

It is possible to replace the script of the EEL2 VM w/o resetting its state

Ah, I didn't know that!

So probably something like (?)

Makes sense to me.

[Spacechild1]

I'm now wondering if updateScript (and maybe even keepState) shouldn't rather be (optional) arguments to DynGenDef -send:

x = DynGenDef(\foo, "out0 = 0.5;").send;
// later...
x.code_("out0 = 0.2;").send(update: false); // replace code, but don't update existing UGens
// or
x.code_("out0 = 0.1;").send(update: true, keepState: true); // replace code and update existing UGens while keeping their state

[capital-G]

I'm now wondering if updateScript (and maybe even keepState) shouldn't rather be (optional) arguments to DynGenDef -send:

but wouldn't it be better to give the user more control to set these parameters per running instance?

[Spacechild1]

Depends on the use case. If you want to dynamically enable/disable code updating for all running instances, you would have to keep track of all running Synths and set the respective Synth arg. With DynGenDef.send it is just a matter of a single method argument. But yes, this wouldn't allow to only update specific instances.

One could also support both, i.e. a send method argument and UGen arguments, but this might be confusing.

In practice, I think most people won't need to change the updating behavior at runtime, so UGen arguments might be fine for the common use case.

[capital-G]

I think maintaining the state can be pretty interesting for live-coding - one can spawn a Synth and just update the DynGen code on the fly.
In order to avoid any hickups it is necessary to perform the update on the actual VM. This can only happen within the audio thread b/c otherwise we either have a hickup (not desirable for live coding) or we would have to clone the vm and then swap it over, but the state has already moved on by then which is contrary to the proposed feature. Yet this should not be too hard on the audio thread since we are only compiling and not allocating (famous last words...)

I think to share a common interface throughDynGen is probably nicer since it reduces the amount of code to write and to document?

[Spacechild1]

If you can't accept any hiccup, then yes, you have to do it on the RT thread. If you can live with a short interruption, then you could temporarily disable the UGen until the async command reaches stage3. (That's what I'm doing with VSTPlugin when the user loads or saves a preset, for example.)

Personally, I would accept the limitations of SC's design and not try to make it do things that it cannot do (safely).

(In Pd, things are a bit different because the scheduler, by default, does not run in the actual audio callback. You can do all sorts of non-RT-safe things as long as you stay within the latency window.)

Yet this should not be too hard on the audio thread since we are only compiling and not allocating (famous last words...)

I'm pretty sure that code compilation takes up most of the time. First, it is a potentially unbounded operation. Second, the compiler has to map the generated assembly to memory, which is certainly not a RT-safe operation.