I wouldn’t dare
Right–it’s a challenging graph-theory problem, and that’s before the actual optimizations are even implemented. I mean, you could understand the whole graph well enough that you might be able to do only local (sub-graph) recomputations, and you could dream up a whole system of curated information about modules’ internals that permitted some further heuristics–like a much, much more complicated version of the new bypass stuff, but as actual metadata, not in-code implementation–but still, yikes. I’ve been interested in this line of optimization for a while but I think this may be where it falls apart, if the need is to invisibly integrate the optimization in the background.
OK, now brings up a design choice I hadn’t thought about before. What if we relax the constraint that the patch needs to be repatchable in real-time when using block optimizations? I can see some real use cases for a feature that carefully optimized a given patch, even if it paused playback for some arbitrary amount of time to do so, and then turned itself off (presumably with some glitches) as soon as the graph changed. It would be almost like a blend between “baking” (in the computer graphics sense) and an optimizing compiler. Parameter changes wouldn’t affect the graph, so the patch would still be “playable” in an ordinary sense.
Don’t get me wrong–I think patching a modular instrument is part of playing it (that’s the main reason I’m writing TapPatch, to allow patching from an instrument rather than with the mouse). But I can imagine patching together something really hairy at 11.025, then optimizing it and running it at 48 or 96 once I was satisfied; or keeping oversampling off on a complex feedbacking patch (where it might really matter), then optimizing it and turning oversampling on; or developing a patch on a more powerful machine, then optimizing it and running it on a laptop (or in a particular VST instance…)
A fork of V2 Free would be a very interesting testbed for both the graph-theory questions and and the processor-level stuff that you’re interested in, @dylan.mcnamee . Andrew doesn’t accept pull requests for Rack but that doesn’t mean that research branches aren’t potentially useful to the main branch either, even as proof-of-concept. Were you around for the initial work on making Rack multicore? Some interesting precedents there.