Ok, gotten a crash that points to fluid.bufpitch~ as well, so maybe that helps.
bufpitch crash.zip (39.4 KB)
I’ve also narrowed down the problem to some “realtime” analysis I’m doing, but I can’t see what’s different since the core abstraction is literally the same.
This part here is what’s freaking things out:
The sp.xxxframe abstractions are literally the same as I posted above, which have since been updated to be @blocking 1 by default, and changing to @blocking 2 with a defer, like so:
What’s upstream from that in sp.realtimeframe~ is kind of like the JIT onset detection thing I’ve been doing for ages, but being clocked by a phasor~:
I tried switching the phasor~ to a vanilla metro, but that literally crashes Max (and I think is what lead to the fluid.bufpitch~ crash above).
Should the first “tick” of this phasor/clock be defer’d to feed into the @blocking 1 downstream and then switch back to the high-priority thread or is there some other leaky thread stuff going on here?
edit: this defer the first phasor tick thing makes no difference.