# Between JIT and real-time

**URL:** <https://discourse.flucoma.org/t/between-jit-and-real-time/295>\
**Category:** Usage Questions\
**Created:** [July 20, 2019, 4:35pm UTC](https://discourse.flucoma.org/t/between-jit-and-real-time/295 "2019-07-20T16:35:49Z")\
**Posts on this page:** 3\
**Page:** 1

<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:** [July 20, 2019, 4:35pm UTC](https://discourse.flucoma.org/t/between-jit-and-real-time/295/1 "2019-07-20T16:35:49Z")

</div>

Something that has come up in a [couple](https://discourse.flucoma.org/t/descriptors-comparison-oldschool-vs-newschool/205/88) [of](https://discourse.flucoma.org/t/using-fluid-ampslice-to-extract-amplitude-information/280/6) [threads](https://discourse.flucoma.org/t/training-for-real-time-nmf-fluid-nmfmatch/112) has been the area between JIT processing and real-time processing.

At the moment the `.buf`-based objects are perfect for JIT processing, but because of issues relating to `buffer~` writing/reading/manipulating/querying (having to do with the everything-is-a-buffer paradigm), it means that JIT is really JIT+buffer-defer+MaxSlop ([minimum 10-15ms, maximum 500ms](https://discourse.flucoma.org/t/descriptors-comparison-oldschool-vs-newschool/205/79)).

This is a bummer.

Of course there are the real-time objects. Those output data as quick as they can, so no (functional) latency involved! BUT (and a big but(t) it is), it is not possible to correlate the output of these (`.descriptor~`-based) objects with the sample-accurate onset detection algorithms.

There’s a quantum problem of knowing when something happened, or what was in the frame. Not both.

Something I suggested [ages ago](https://discourse.flucoma.org/t/onset-flag-for-fluid-nmfmatch/136) was having some kind of `@onset` flag for the real-time objects where they don’t output a frame until they are banged (or receive a 0-\>1 transition to keep it signal rate). That would solve this problem, enabling cake having and eating for this in-between JIT/real-time world that I (seem to exclusively) occupy.

So other than prompting a discussion around this idea/problem, some specific-ish questions.

1. As far as I understand (from the threads/discussions up to this point), the JIT approach will always be “slow” because of having to read/write/transport `buffers~`, is that correct? (As in, although it may be possible to optimize the underlying algorithms, the functional time the process will take will always be orders of magnitude greater because of the framework/approach involved)

2. Will it be possible, at some point, to be able to accurately correlate the output of the real-time objects…with prompts from the real-time (onset) objects? (either via an `@onset` flag, or some other mechanism)

---

<div class="post-metadata">

**Author:** ![tremblap](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/tremblap/32/5_2.png) [@tremblap](https://discourse.flucoma.org/u/tremblap)\
**Post date:** [July 21, 2019, 9:04am UTC](https://discourse.flucoma.org/t/between-jit-and-real-time/295/2 "2019-07-21T09:04:28Z")

</div>

I’ll leave the two-point-one master brains of the project reply to this aspirational proposal, since I am quite excited by this… but at the same time, dreaming as to be reminded as aspirational 😉

@weefuzzy @groma and @a.harker will have opinions and words of wisdom here, I’m sure.

---

<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:** [July 21, 2019, 1:35pm UTC](https://discourse.flucoma.org/t/between-jit-and-real-time/295/3 "2019-07-21T13:35:09Z")

</div>

I look forward to their musings.