# Descriptors comparison (oldschool vs newschool)

**URL:** https://discourse.flucoma.org/t/descriptors-comparison-oldschool-vs-newschool/205
**Category:** Usage Questions
**Created:** [May 26, 2019, 12:04am UTC](https://discourse.flucoma.org/t/descriptors-comparison-oldschool-vs-newschool/205 "2019-05-26T00:04:57Z")
**Posts on this page:** 1
**Showing post:** 67

<div class="post-metadata">

### Author: ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [June 9, 2019, 1:26pm UTC](https://discourse.flucoma.org/t/descriptors-comparison-oldschool-vs-newschool/205/67 "2019-06-09T13:26:42Z")

</div>

> [@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](http://discourse.flucoma.org/t/anaylsis-on-segments/223/6).

> [@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](http://discourse.flucoma.org/t/onset-flag-for-fluid-nmfmatch/136) 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.

---

_[View the full topic](https://discourse.flucoma.org/t/descriptors-comparison-oldschool-vs-newschool/205)._