[L2Ork-dev] damage-control scheduler

[Jonathan Wilkes]

On Thu, May 21, 2020 at 1:08 PM Matt Barber <brbrofsvl at gmail.com> wrote:
>
> Wouldn't need to be a phase vocoder necessarily – it could be done with a rather crude overlap-add and a wide hop and still be ok enough for what it's supposed to be doing. Simply interpolating over the data would cause a probably unwanted pitch shift.
>
> I've thought about the DSP graph problem. Miller has communicated the need for this at least in [clone], so that you could allocate and destroy instances on the fly. The constraints are really hard if the instances communicate with the outside, since there's no regimented bus system as in supercollider and csound, so the web of connections is potentially much more convoluted.

Btw-- you might have a look at the "canvas" field I added to [struct]
in Purr Data. It caches the binbuf of a patch file which makes
creating new instances much snappier. But of course it doesn't address
the bigger problem of dynamic memory allocation/freeing when the
binbuf is evaluated, which is a big no no in terms of even soft
realtime safety.

That said-- I think we need a new term "realtime shnafe" to describe a
lot of the behavior in the Pd codebase.

Example: a user builds a GOP interface and gets constant dropouts upon
interacting with the patch. The gop contains over a thousand objects
which aren't displayed but still get searched anyway on mouse motion.
I give them the workaround of encapsulating most of those objects in a
subpatch inside the GOP to reduce the number of objects searched on
mouse motion.

Thus, GOPs are realtime "shnafe"-- something from which realtime
safety may be gained, but only after treating the interface like a
speed runner would to figure out all its "wonderful" secrets.

A lot of realtime shnafety is frustrating because there's no
conceptual roadblock that keeps it from being upgraded to bona fide
realtime safety. I'd bet most people reading this can quickly think of
three completely workable and backwards-compatible designs to modify
GOP implementation to eradicate the problem mentioned above. But once
the userbase accepts realtime shnafety it becomes infectious and
difficult to impossible to address on a larger level because so many
corners of the software are affected by it.

Regarding clone-- I think a good test is to imagine a user who wants
to clone an abstraction which contains three [sigmund~] objects.

A realtime _safe_ approach to clone would view the contents of the
abstraction as largely irrelevant. As long as the user's CPU can chug
through the maximum number of instances they choose to create in the
given dsp tick, it doesn't matter what's inside them. The only
approach I can think of to achieve such a thing would be to a) specify
an initial max number of clones and b) pre-allocate and use something
like switch~ to simulate creating/destroying instances. But perhaps
there's another way.

On the other hand, a realtime _shnafe_ approach would immediately
question why the user has three [sigmund~] objects in the abstraction,
advise not to do that, and imply an eternal journey of measuring and
remembering the non-realtime safe instantiation times of various Pd
objects to eventually arrive at a generally workable notion of
realtime snafety.

I'm full of rants today!

Best,
Jonathan