That’s great!
There should be stuff in the helpfiles for this, as that (potentially) solves many of the n
amount of buffer~
s problems, and after alpha02 my understanding was that polybuffer~
s were a no-go zone.
Might be useful for @jamesbradbury’s problem with scalability in the thread about analyzing slices.
Yeah that makes sense, and doing this pseudo-realtime/JIT stuff is just something I nabbed from @tremblap as a way to being more precise with analysis frames/windows for realtime purposes. But it is actually a real-time process that I’m after.
Something like your (“deep fake”!) screenshot would work well, but is pretty different from a conceptual standpoint to how things presently work in the fluid.
-verse.
And if there’s a click~
triggering it, it could (hopefully) theoretically not be limited to a hop’s worth of resolution and also account for different @fftsettings
per descriptor type.
I remember ages ago asking for something similar for fluid.nmfmatch~
where you could be very precise about returning a single frame of analysis based on an onset.
There would be tons of uses for this “real-time-but-only-when-you-ask-for-it” type workflow, which would alleviate all the potential issues/problems with the buf
stuff.
Totes, that would be great. And obviously makes lots more sense for real-time stuff.