Descriptors comparison (oldschool vs newschool)

[rodrigo.constanzo]

@weefuzzy

[a whole bunch of stuff about how fluid. + polybuffers~ = ]

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.

@weefuzzy

But let’s imagine it’s a thing: you have some Rod-grade onset detector, and this emits spikes on events, these spikes could then be used to align the ‘re-starts’ of a bunch of feature extractors, and to some kind of summary object (e.g. a signal rate stats that doesn’t currently exist). At the point that this produces output, you might be interested either in message or signal domain output depending on want you want to happen next. If it’s some kind of query, probably a message.

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.

@weefuzzy

Even then, the things don’t behave all that differently (at the moment): the reason you get more frames in the buf versions than you expect is because I also return ‘padding’ frames where the beginning of the sample to analysed is lined up with the middle of a window. This will possibly change for descriptors (i.e. we’ve been talking about it) because whilst the current behaviour is correct for things that you’d want to resynthesise later, it makes less sense for descriptors.

Totes, that would be great. And obviously makes lots more sense for real-time stuff.