@blocking 2 - inconsistencies?

Perhaps this is intrinsic to rocking the @blocking 2 thing, but when chasing down gremlins I found that the processing time of fluid.bufspectrashape~ was varying pretty wildly. It generally takes a nice consistent 0.3ms (closer to 0.4-0.5 in the larger patch), but every now and again I get massive spikes up to 4 times as slow.

I thought this might have something to do with another query arriving before the previous one has processed, but that doesn’t appear to be the case.

Here’s a patch showing what I mean:


----------begin_max5_patcher----------
4171.3oc6cs0iaabE940+JXE5iqElabFx9PQRZZSApSZPsKBJLBVPIMqVZSQ
JPRs1aBh+s24BIEoDuLTZn1MsZQhVtjb3bNemqyYNh9We0MyVj7Yd1Lm+jy6
ct4le8U2bi5TxSbSweeyrMAedYTPl51lsLYyFdb9ra0WKm+4b04yeHLyQ7ew
7G4oNYOjjlK9c9CAwhO3NaSSVxyxBiW6jGtgWN7nvX9xjcwpmAt3jw61jrKO
hmqlQPwYCWolmjEe30Hb43WrawhHt7BvhyrMHe4Cho4tT9xbMiw78lCt0AQP
ycu0Ah.x+xENG37y6mwv3xIDJO2u8pWI+31yDUvycx37MYN4INK3Nq3a4wqD
2nShFVx344BhMyIQhZOvS6GY1lxyDiNHOLI9tSC6ftcic2mDmeevxiNWV3un
NmB45Dlc8fyQ.O.BCz+fnBXlpfdfq7WLPMLWO8aSB0L.XNpUgQMxHNXihLl8
24QOxyCWFLyhhpmR14rIb8C4NY4Ao4NaS1tUptJ9syxjz3+PqRFjw3NXlUPY
hBIIHjFWIp+h1otr0guM6hxCyhBWwSm0JuiNl2IvYULTpfJDdFtiGGTn8Uxr
Bagr7mzmqTcV+byeZKWy8ylcq3+q3UwPDLqf9zWUYXW2ttE7Cq7EP7AZ7ioF
h7jSuy.zbm7zmbB1kmrQXBu7L0nv9SkkLVnjI7Th03IRgQtfgzwzTQlPyntD
b5Mbgyc1DDuKHJ5IA9FtdsL9SxlpXNh3amGN6MU3LxEqQXkULB5+x.nuOJQL
uFaciolXc2pk7hf306sluOIUXWHuLsGcSFUpa5hUZkTsaPjMMei4eRvVGolc
e6.BrE.oxc2QLs.Zkb3OOH+U5fxW9GcyenoW7hXWRwK0i0HIBH1Wv+tZ2z.r
8k1K1kmmDarrE4cRnQSjnsbTIdGy2POs5Mo7ymO11eZX6VE2SHa2gssHCus6
jqKI0bibfoF40iG.Q8EOnckenR42CzutOpsv.ecZXPzr5SnfC0nSA7HFPXjb
IaYhkTTiUuYVv1s0N8M0FhDS+Ph5A4ca0oBi0mBVcpT9igki2s5rAoB1NWvy
6R0D4mojY6eLIhDKi2EVIfUR2BRRIGkLW11hXtJwc4kqYMoW1gVOhRTwUYd0
zjD5IqiRV9Q9pZ5uBQoX4Ygw0WkUiKuheefH826ZHQgyc8cgdT+xeZ6tKyQn
0GUqhqalsNMbURrjjZHWjmtbxeuCTsb.4m6YM0cDGrskAKzbEfTGWTrtm7cY
KBRkhsBSaT4EySRhZdopwEwuOu3xhULEe.llmrs6KlJWvU2WdQh3ha56YqtR
1c6h0W8NgFR9cYAO1DsyEIGVX527w+4f3PQPItplDp70ptn181CYKSShhZvu
5q7XKWYkPieI+SgqxePul1ZxawsGtsTkZVkTdU3ZdVdyykGrNq4YpVXTsSsa
QgE8c47MaiDbQyaPXqDlkm8PxmxJtwREs5.v9p+T2ButezFm+.+oZeeUluck
N8QKFt9HZcAHJsZlNdua4mUp3ckZr1KQw5DjSVXrHR0iAQNgwNaT0mJkuUVZ
pU0K1hl7hWw+bM2NEwVJ7.ch3Si3MMi4rvA1MtAaG2P0GQ+QaONzSWNp5PF.
0qMloqcFSuBESkAs3V6xfph33KkN1GMzh6EZaFR2VXKTW9lhZj8xGbesvi1n
AVxkDXKbbPTNNvp581OthdIfqmhq.2Knq.h2+O4IfdIUXIL0dR7RzQfZNGM5
wFodY2dGILSi9C5H5ub1bxDIflI2zIYw7ChWUjAfHYfhbCZMI.zyNP5c9.o1
t0Z3XfD0J.xdAu1xfZ+xSjUgsijNU7f75sipYI6RWVh.EXjSS9QjmcdXb0R2
dekyR48YjLcrz.yPZ.Mgz.0PZPDK1ANQzfqgz.cBwAhgz.bBoA7HjESEMfLj
FvcRCEmrr1KyjKod0c5xGbWPddZ3hc4Zy35ESZTKy0rxnrNJYQPzAqfss0J+
p8rvHqJH+WVEr7KyLt8Cny5o985P4TYT7aK2sVWaV+9Npg4xnvke7KlWQWRm
0uLKbcrvydu6RQQBKLE+g8uX6BSFOpJYYC16ht2IFU.zFalbOrIVkXldwE1c
yXxSVuNhatTCbR0gW0iE8vmH89nUvmWvBu+mEqnzyXtG5M6L4vhsUqfOspjT
7.VLhdh.ZqcMssNwg.NtSbf3p8w+YdOzfjoYyjHL+NY6KnN8JdTvSNXy2IoY
mLG6BQsvwr5o8+rpiimPcbD9XVWW2moPEej9ogvIwOcqZ3Zl9BpfKXmzDGBv
Xzvelcso8TJ3T7Dnf2NGm6rvIzYQ6LL9XF1avzNjR5aMj+kbIU2KVP7bBjBH
zBzvEZaE8M7rrf07iS7Rt7+6k5xN+QnwRd2NAhALtoGK0EGqJCo+ETrCEys4
ImMyp10Ea7O4x0hSK1c+87zu375W+5jXY6X57gj30QOMOH7dyc5OPeQb6oZ0
65izE2mZe.Yj8D0ksi2PTsd.8kRSPwll72vdJEdrK7ERWOQbmHFUKJmPF0d8
4DgY+9bpj+8nW6roqc1z0Na5ZmMcsylt1YSW6roqc1z0Na5ZmMcsylt1YSW6
roqc1z0Na5ZmMcsylt1YSW6roSuylFtP+YaE7cZPT1CAa42IKTRlyWkErQDY
ARbXFWRbOxjU2eLbNjAodXDBA78P9xbemhcAXjnUINwFALQ.SELQ7oy8.9tt
DWO.FQoLZ0K3hKyWP9ncgqlK.KkRzWDnix3sMXSok0ox29cZD67UBpUcbl7O
VHS6UFjFotvJdZ3iY66GLCdi3zxl0hbGb2ZqDMmfXQ+lZAK2.2Z+.gDoH6hJ
VpC1MDOEa12WcOOPV65rVDY2eed06pHjK0gRjMeRcwi7r0DPmmLAimRYh78a
BCg87ITDEBo.lm3jBG0SrD52Qukn7eY9VhBV8nOwWyQpGbyD00RtCSDoP9cT
BHvFYh0eFwkpvoqzaNU6slfoyLxfI1aeZOm77fOcFDdVSLDZvL6aANDhMbhf
m4D4av7.IVfi7zDauSjqklGz.yCwVSzPHGFagIhYvDI2C7yVWfZxDAmBGGlL
yx2YQ0zfplYvjOyPuovWh6kR+gXhBD0FSjqoZpmc..SbOxlBolQyLpIPrLIR
2dFEu++1+Q82DfVRgFaRHJrMD2x2uPCCErKU79NLROOzDYR7wRf37lIOSmoy
0MOxn7CoSg0i4Ss0cziflFiA7rL0G.M1JgUSzpPSBWa1TClDt1n7IrfojQK0
BOIrnQVR9CKX0K27fFNTNqGzngGzjgG2fgc2bgG1XgpBaqaqpCVh69MTc2pv
j2p5It69dd7N8Z8K6bulXyh02GFEUEjsdIwKKJSQH3pdYrd.YjOAB8jAjwPL
StVewQhCbcq4EpXLvxAQbI9.j7VITDi3pNxCgcwpH6GLLz94B.80y.v2CPzG
INErQt.BrLdcQO.xp0HaaSSjaeZYqQNGWUnd4ar20oAqBK11PPiBxeagpUp3
pG1Ma5WWxkiotpXkv3M6VFbtBfJhqCYfg3RSofWE16w.tdd5i7H3VGVkTf5J
lD48Rk+vzGoeRShPnsz.ILWHVQ5Hermu9HWHf52LqvfkKEOsFCEiDJeJDhTx
HR0UxAijGw2b3PYdB9UCX.nmm9HwSAgZN1EqaLLe.AxTSofRILldXHe8ixkV
6sccjv9W.MMmUjfsTzIjxPZKDO.PV8x5SprXipwcWXrzYDuR6.6ifTMBUZ1g
NVL2n1ZBOf+ys7Xm2FDm47V9lvEIQqlU5t+LMH99f779LHpW+w2WKUl50fT1
pEyAVhf9wuN+N0v.+ujcpwCaJMT8ckAHz54DFPw7RdGOrgpY9YNTq.0mcnFp
a6n5OwkQbQv38iDpWvouvz0USPB.kgMz7qyUrdf8ltInrjF8O8t+VepxUoI0
T8TFAW4eAhftTsSRolixkgeMX8YxPvLW2O6YMzlc.Tlbj1euT4Wgnrxzj52N
vEvnJhFPcwPkc.THfP98ZG3MPrLBEBA5Du7QThBeb8gdxcJqmXYPJVXGqnAF
g56WbDvuWc6+9SqRSVyiemR8vNp3pccKb43Uy6zf7DyDdueZrOS6kE6W3zSd
JWrcTOavDdUA0O9nSRotujsJ7W21QCn6Z5Pap752s9mYX746M963w7GCrrt5
2T6amX6ZrGG0wqR8.TbDzZ48TPVea0WcqWPD02EDF+ECoJg9akS0iOx9jV1m
BENV5i3NxT.Vnus+iIglPunHp+Q8+YDxLcqCnl9BfYnqkCbfzoCf1W70fyhM
wq2vWMN6v13i1vJ5Q2rMIaw54RC+7x7znyf5sJAI+hb2qyCKpPcQc87CIqJ+
W6HC7JZXRB8D88jvIqxvixEBXhUr9gZudjZmXZyKxwAMm.R6GCWlOLV8rKO+
QYqqk+hKai2tLYK27zM1W0Zer7mVWLwyGH+tfElyJF50qMMmA8uXUlRjR+hQ
m.c64SzxJUlVGGuq1aWLajNaOBELSr.cndDDLTsdRRw1pXSV5euYfMV5Bln4
OE7HW9p14KVGgGeVgf4tVh4VEj9wWGKeMS7ZUkLFeoNHUlkrpJ+WsG.dJB1B
U0CNfpm0K9g0qnWyheTU7fQVI81bqLX8ushlxGJ9NFA.EeUIrwiBMd8s8kr+
nCrWY15oJvfemoocXh2tctGDlx1GsqBKh3hPl5Mx6aRR93LqoxEF+wSQC41F
eZg5uV8nEhEfWUXbr7a8Ao+8SX57WY48R3HWRCyriEbZcK3FdTsVtggG1gk0
0POrGaVreiUTyBt9QCGHuOJ0JlIeTulreR1ZOO2IKEISkX3TnaUhVk0fakOm
Rqm9pMBvmTzbF99XOVwQLOqF8aSvmoUuL0LrzmB0qlqagUXO2I2bfXATyY8H
1sAqwv0dyLXxp7PXWjeyXFRKNnsIqFucYsceTTqiHJ6HfiOpGu2LOYOlcaqG
cAyAXr97OOsplVGlIEq+tQyzhtUqm9rd9s5u4qeSzNd46eMiMywPVwFVu2Gl
ecOW1j.SS9T7novA8sZQJ7u7Tv3IP.x2U2f.LFFizVaHnHxq8IvuKkyOAJTg
dUkhCRk4SXeh66Ed1hyCFM44Q.TptHgTff3TPI0G56ZeZ7ewWMZ5iUk8KrZs
EfhHF1l99O7nnjOMdHD4pa8ElGzSkxNvUnUNXuf45C.dSACf98HCn19huKI5
DTQppdgqHiIWcG.UOHnUHvs6R2FMPxCGjfIAnyqA4Bn9JcXjmKE4YX+fvp5D
PBzU31P4aS58vpllo7k7vG6em6ZSmoZsP6INP8VfzNDmdIJR0Bii3SIBGZ9E
ABXEszrPa1G265AtLZQY73UYuzhfrGj6216fNVkAAL89LQn.+hNGmAGtqAuL
Pcdv1g5j6ZEi5MA4INuQtJzYVa9yx42uKJJebavh7KsBSgNzpr6kkBXntezy
0EpKiNEyv5lpmJLIo1ET0L0DwSVb88HOlmNwFbkoCF4i88rJdHe8a8R56Kvm
jUy4owW7SnuOPm8mPkgTrk1T..Ca1f0MIb4+VlMPYr.RIuZ4r3BAtvAPwNOX
TXvQzq80rm+1vz7mb9qqSNIyY8WctNdw3+pe6U+W.4iPqN.
-----------end_max5_patcher-----------

Now what makes this particularly fiddly is that it seems to come and go and seems to be impacted by the rate at which the process is triggered (the metro in the patch). The numbers and timing here are setup in a way that a query never arrives before the last one is being processed, but it still jumps around a lot.

So I get something like this:
Screenshot 2020-06-22 at 1.54.11 pm

(in the context of the actual patch, I don’t trigger two things in a row like this, it’s all being driven by fluid.ampgate~ with @minslicelength 1024, so in reality no slices ever arrive closer than 20ms from each other, but I still get the same issues I get here. the delay thing is just a way to isolate the problem for demo purposes)

I tried running the same process with the “cloggers” from the fluid.bufthreaddemo~ help file, and that doesn’t seem to have an impact (other than slowing the UI down).

Is this just “how it is” when working with @blocking 2 or is there something else going on here?

(p.s. you can swap out the t 1000 for random 100000 for a more “real world” variation of this, but the results are the same)

I think this si just how it is: the evenness of processing in blocking 2 will be a function of how much other stuff there is in the scheuduler queue (including the previous job) but will also not be completely immune to what happens on the main thread, e.g. if Max needs to temporarily lock some shared resource.

Check out the ‘immediate mode’ tab on the fluid.bufthreaddemo~ for a histogram of timings in the different threading configurations: its tighter in blocking 2 but there’s still some variation, and you can end up with the ocassional more drastic outlier.

I think @rodrigo.constanzo’s next step is to learn C++ and code using the clients… but that is a big job :slight_smile:

Max prototyping, then C++ optimisation, could be a fun workflow, but that is starting to be far from playing the drums… a compromise approach is probably to learn SC as I think it might be more consistent… once we have all that server-side job stable… the problem with Max is that it is quite not meant to do JiT. FTM used a way, FrameLib uses another one, but this is a hard problem…

I had a dig through that patch to see, but nothing (in the help file at least) jumps around nearly as dramatically. This all stays in a range but then has wild spikes in there, with nothing else but this patch going on.

It’s not doing nothing (fluid.bufspectralshape~->fluid.bufstats~), but it’s not a lot nor is there anything else going on in Max at the time.

edit:
I mean, I’m not asking for a lot. I just want the perfect information, with zero latency (as a compromise from “negative latency”), with zero CPU usage…

This is literally a quote from my keynote. did @a.harker send it to you, or is it just sheer luck (and vindicating my artist hat description)

really? even with the crazy cpu-clogger I’ve put? I get some range… although your tolerance is super small (4 times 0.5ms is 2ms, so this is nothing considering max’s scheduler is at 1ms…)

With some twiddling about, it looks like there is interaction with the main thread (presumably thread sync for buffer access) that we can’t do much about. If one strips the patch back a bit, to a single CPU timer subpatch and no button objects, and turns the metro / delay up so it’s pretty stable, you can see it jump if you drag stuff about.

If I run it in a profiler, you can see how the bumps in CPU usage between the main thread and scheduler are quite strongly correlated:

2 Likes

I remember you mentioning this, but with regards to @groma’s experience in working with musicians. (them being much pickier than CS folk)

Fair play.

In the scheme of things it is’t much, but when trying to eek out every bit of juice/speed, this popped up as a slow spot. Surprisingly (or perhaps, unsurprisingly, I don’t know), I only get this jumpy performance out of fluid.bufspectralshape~ and not fluid.bufloudness~ / fluid.bufmelbands~. Both of those seem a bit more stable.

(mid-post edit: I isolated stuff as well, and it appears that they all act the same. In the larger patch I seem to get more spikes on that, but that could just be the luck-of-the-draw when I decide to inspect it)

Ah the Buxton quip as I now call it:
https://www.billbuxton.com/luthier.html

1 Like

So I was tweaking this a bit more and isolated the part of the patch that does the vanilla onset detection -> snapshot~ stuff, that then produces the startframe for the subsequent analysis.

And the timing for that was pretty erratic.

I kept isolating bits of the patch and the timing of stuff is crazy.

Take a look at this:

Weird things happen at diff metro settings too. metro 103 is particularly bad and gives that really obvious pattern there. metro 105 seems to create a pattern too, but not nearly as obvious (or looks more aliased/intertwined).

That seems weird I thought, so how about something more “in context”, with the actual bits of the patch that would be doing it:

Also a pattern (and really fucking slow).

What’s even weirder is if I take readings in the actual patch itself, I get erratic values, including negative latency here…

I thought it might be some audio-rate order of operations stuff, so I chucked a delay~ 1 1 on the signal going to the sah~ but that had no impact on this.

It might be time to look at @a.harker’s fl.libLand @tightness really->fucking #fast. (I will probably send a polite and inquisitive message to @jamesbradbury too)

The “slop” shown earlier in this thread will be unavoidable, but it would be good to tighten up this chokepoint where the msp~ meets control rate.

edit:
Here’s the code for those weird timing examples:


----------begin_max5_patcher----------
4243.3oc6cr1iaab7ym+UPnOe9v9f6q9olzj5BzjzfZWDTDDbfRhmLioHEHo
NetAw+169fjhThjZozRcJwmAhLyRtbm2yryLb8u8palMO8ov7Yd+Eue16la9
sWcyM5gTCbS4++MyVG7zh3fb8iMaQ550gIEyt0buhvmJziiHTu7f0ahCy8hR
7VmW8DIaWmtsHNrPOeP4nQK0yJc9u9Ze+pGcSPwh2Gkr59rvEEFfBQw2Qt0i
HPp+BBD2At0CAtC38K6d+QIUudnZre+UuR8ysVhQIgeTBFGfPu1ibGG3K3ht
wDXGXBp5QMOWwm1DZPiYODmFHeu+R+XJTPT3FQ.TXJkpQTTeHJ5TPzsqmGl0
M1fNDavnc7krf0gEgY2GlDLONrIi7.Lc1sdylGjrZPjE4yU3GFqQYvv35ovT
KRWsRBn1x4v3SBWiRNBOsIZh7q9cxkckHPVpTaA68WCVTD8XnGzdRgeuBwGk
sVhubl5WHT3dY34aKJRSrGYHmDe0VDEdw4rEdy8lauJLcXd4si.U4v6nM+Cm
dbqTmBh2mCFIk1ZWJnZSWOjlTjG8+zXsRbrezjYr6xMFifZblcIPLvXPL7oh
Xb.epPr0aiKhxiiVNBmKHeaTLykufhOYFCOjCmcRvxoHQGI7Ytqga1.a62ya
IqGCz+Ezm3RZjz+u7cXO4g3HeuOjlsNPimziS.LVyjtMbuV8HsainSicaYTp
5HNfjoxt8XQT1D4fpLZxoCQ6wA0FuEa1VDstOaAcQC31F1bSidPzfV8JweSr
k7iDgIpw6OQxEzf1WkEED2ZqIRbxPOJIHxIDEG9XXVdjjkuC4tYVvlMMF9lF
SQQE+0T8Khea8PQIlgf0CkE9XT07I0iFjIQzBIVtMy.jOQqLjpdMoRSvIaip
YoZ9YIHo4bJjKeSvByjUL3pauizwL5Hbj1lfuNHNFugriTxXUb5hODtrgLpj
4sILIJYSVXtzKWPQIrWe6kgODHcTbeKdH7Nhf.4TQ0e55oenDd67U0I65lYq
xhVlln.oV7E0vUKtTHQKi.IMQM8SjDroiIKkUkDodtYtDk2lOOHSw1JUeQU2
rHMMt8spmWb3CEk2dSTRxdzzhzM8eyrnUuef4NOUdy0C8t02I+9sIl6duTBo
397fGaSsKBhiKU1a+5eJHIR5bITosqQWP8MMlvde9hrz33V3q4NO1wcVJk3W
D9wnkEuWuP20feKe7nMUhTyp4xKiVElWzdrhfU4sGoNDhFCscdoF88Egq2DK
wh1OfTWIJuH+8oeLu7AqDzZR.1k5jlZ3Msb1Z78rfZr1Uq91W7e6atD1bFcX
5C6aBwy3EmT8asH9gV+abipfTUKlb2sgYOFDaxmiWTtWV3lzrhvkdR5QXSvH
JYY3SML6T5MozBzIReZ4gosWl4dv9oavtoanlyXXOpG5roOCU849AvLlM0Te
VUj21wC5vr1kgpJ8buPYXezjV7fj11NwcEsEBzx4FmU+Af39ZoEsQSX8ujD1
RCG9ZCGXcBWGlthtFnqmho.xEzTfI8IeoXIfdIEX8YlhBbEZHPulil5wFobY
+VG8Y158Gzi2e0p4kKC.M2SFfmbQ7BRVVFAfpDOlXC5LH.zyNgje9DRidqyn
iAJpVIgbPhWWQPsa6IwQI8EzoFGT2uapZd51rEUTfx3g7ZiOx3rKhRp251OW
6bW8bVwSGKLfsDF7mPXv2RX.Ngv.wRXfNgv.cD7B3DACLKgAzDRG3VBCjdgg
xAqx8xL0VpWduI8A2GTTjEMeagQMtYxjF01bsKMJqhSmGDu2NX6ZuxuZGJLs
UUFAmtpJyPlDXS4WIkUFJljxJSagmSQxc6sKOFQspfzQWqJpOQWDtoqVUtnH
bPzohXLL8ZpHbhqmZvQY5mpjyOM0faBZVB9o2qDkJwHDZxZVh7EoaB+r0x0r
A5CKlPakw22vXv69KG1eRcyeVDGs3Ce1ZVBoWVRdzpDYP2C5AAqUMwbM2.Kd
1KDp+zTdvJguoyCha5ekyu8UJwTLjdYZekdv6vkq5SSrqfjNe7tTRtTg0Gcw
vzjzn7P6UWgmi5JRX3fXxgLWe+KFJORKTP14fyXN3NHhh3PFlK+EQ5g.LEVu
FYar.gWx1XoLFBBkbszFKP7zX9tR4V.tRZiE3T4mxvRmPD0cswBj391XoRj1
j.xWZikWZikWZikWZikWZikWZikWZikWZikWZikWZikWZikWZikWZikWZiku
Xaikyub8+4nsEtFZeiqg1X4ZncdtFZqoyu8t9xpMV5KOfoO7PdsoaKpHb+0r
Z3z5SLozEguC23OHB+1Ra38m2OvWdY2Cgnln7olpbUVGSvjjdOzcfWRn2KIz
6KkD5I09xCVE14NpLVC8nsRUhxqzhzslHEQtcuVGM.WDwz.MjFM8GdvPbcYb
8spS1IlPjAJY14rCJhei8pePky5o5YNhrztM6ZKB8sI4RGCxcQ79fBOkUKoz
bwm8JB9fdvPOk5d4YIkz6qdnGknUZlWQpWvioQKq2ARd91v765UVDO1jRiNR
RoQvFGnOPSUI8YWJp5.Y5P5PSZ4eY6nUFwN1EmmRXYw1gxXTXRexPeNkCo9.
J5VONY+nWd1nRu9DRxFGLHooYu5dDpCicGmvv.lO1GvQ.LTRVD57ShtT1qFf
3DrzDqfWdzpGy6mNg5gNAGVD5V6nUXxNELy4H0ki3bhUxBOyNkCJ6NBCJj5G
LDm.IJkCb4YNyoTXqm27tnLYX8l8gsdtzrklco.dVy..eJSAf0jmCyUPM4AN
MeeK.KgrJTXZfB3AhE8vk.OqIn34K0CiqkQg.x42znHAq+jPb4Zgz5fBsu2q
.zy3n2r7TgxmJZ2EkHgpw78mfShyd5iz2KYPio2YAryq6Y0baLiYNpjtX72k
gwAe5yJxt5+FA5xcA5Jc1d.WV.uXL47f2OFNrvAnLh62ReFyfp5MhNrOhsh.
neh1gRXnG66CnjpbnC5V4ltuZkznfMGP4sckPbKVIejKVIhM3juCVIsk9itT
ZKhMdpEowlr2V98Xs6GcolOKHBSsAfXN.2wsBlrOprSVIaHxXpKVIazFvMJa
2ouRXaWoyFm7sYkHNQavFgOjKXTHqVItCXTHlsqz4hSVYezErIgEKjKPHDzx
E5b4Q1XenMar81dOcRoMXnvEJwVrNtPE1JOmcSIgmmrhMtsvNhRdLuVPWnlY
kYWWnNaUDHBmXemY0Z4FeIbqVKlSVKwIDE25nkaRiRJJC7FCnpzGig76DBAC
RfTAhA3Pe021Kom64Z0HaQE9TXMjislLB6IXXhf.DLpPkSdpPEULA.EHg.yY
BI8CoFRH39Delufv8gBtKBaFZUb7PWHrYicAnSTgv1tRmq+WHyZaPsWJy1W2
q4WTqxdM8xdM7xgM6R+M5x9M4hNCkl58u2Vl20lHaWFk9VcAXt+6CS1Z11eU
KkzlVLe0CQww0BwMysYU9AJEwq6qllB7HgODxUB0XHlgn5qjWPHMyHqYNvpI
IE9E.slfOEw7I5q3HLAq2F4dSCsasjpRlU.H3.eyUxgfkZP0M1PxpxlSg0nC
K1jkpZT2ptz4NbcKgErsHcUVvxnxpg.Zk+0aKEkxj2c+1rvbToTMmlhd0Liu
a6hfykATCb8vCrjtzlKvqo8bFfv4lq393NmVMWfJMvoeVcBuXlqLuoIgIzkY
VeFAh0fNRZXUXth.0Vba.DyBVrP91ZMULRJ7ooP9UHhRb0euYFFGtd+ox3R7
0Pv.PN2bk7sfPsm67Usll.3CY5kTBo9LlYZHg4UQnMNpahk5+RRS6UU4HQCm
PJCYzP3.fxsbyEUkSP87tOJQYLJrV5.KPPpgBUo1gNjM2p4+kV79WaBS7daP
Rt2aCWGMOMd4rJKemoBw2GTTLjBQy1g6ma3nsYazoJD5NelmI.8ieUw85oA9
yjdp0SaJUTEDkCBibtOCnQdEtiOthpc1Y1Wp.MjdngT20UMeiKhCkNi2MSnI
6lBopKw.PRBJCao52goGsa8MSqc5HI5e5c+8gDkqCKps3oxCt19BDAIlfWwJ
IGSLqMHqOSJB1Y59YOpgtzCfpfiL16UB+ZJJqJLog0CH.FUCz.JAC05APICB
IFTOfeDeY9Tnbet5.uDHpul9PDPoAhA8kAoXodrFFX9Tgn7JfXPY6+wmVlkt
JL4cZwC2HhqqMVzhwKl2qB4IFI7N6zXAyXkEKJM5oFhfci3YKjfW6T+vqNIg
5gB1pzdcWWcDYWamZagWQ+xe1QiOeqwuILI7w.GKq90M5u2tkXOzqCuV7.Td
EzYw8TBVeS82TvUDP8lfnjOaITIkeqMpd3UtGzx+XjzvxP.2ApBvR4sc+LIv
D5pBn9mMOBQsS1ZOnYHGXVZZYOCH8Z.n6MeczUwkzquKb43zC6BO5hVQ6oD8
tArk6mKK5oEEYwmAz6T.R88OLnwCGJPcQM87CoKCys1pnkAILf22ShN4TDdT
lP.Srf0Oz33IuafoKqHG5zbB.seLZQwwoUO67yeT8sRVb0Eswaab3FagT1tr
VKzs.Wmal34iH+tf41iJVZ0qKImiZewoHkLj94iN.5timnicpLsFNdWii5eW
DN6.LELStAcnYF9Xnd+j9kkUwknz+Y8QJrzELPyeJ3wP0o55mcNEd7QEBti3
HjaYP1Gdch56e905LYL9Tc3WqVxpy7ecM.3Z.1AY0CdDQOmm7CmmQu1I+nN4
AiLS5cYV4n4+1IRJ+Z4mTB.T9cy4hWEZ7xa6RY+AW3tzrMPVfA+ASRa+.uI8
VCBaQ6Cppv73PoKSSg795zzOLyYhbQIe3TjPts0uNH+q0uZIaAvqciio.oJ5
v0SX5rW43ZIbfIoiirik3zYI3N9r5LcCGeZ6mVWKsvdnZwtBqnWEbyqNti7g
fTmnl7Aydx9IUq87bGrTrJThiGBcmbz5nFH01bpzdFJ2H.geYyYna.txqXbm
58acvSz5C1GKS8oT7p89VXk5y8hM6wV.MLVOhpM3LDtwY.nM6xCgIHQaeFJM
NnqAqVG2KttOJZzQDUcDvgWMf0aFW0iY214UWvX.FqM+ySpps1gcbwlmcA1l
zsF8zmyiu070O90waCqNousVMGCYkErdmMLQSKWtD.yR+XxngviZa0gP3e6S
AiG.AHAwzf.LFFiLZaHnzyq6Av2jEFdBPnl5UmJNHUEOg6AtuWZYKoHXzfG2
GPoljDRARfSSJoBnf3dX7eGtbzvGqN5WX8dK.kdLbM78eCiiS+33IgHho0WX
bHWGxtpS6OdufQD..eJP.zeDQ.c4KdSZ7IHhTm8BhLhIhoCfZ5DzI.3lsYah
ORvC6EfoOvDWCh.nBsLLhSnHtk8CBqtS.8gD8+RWIYUJqGNU0LKbQXziCW4t
tjYp2KzNfCzrEHcCvY1hhRrvZO9TeoAMQoi.VYKMKklE3A2OvkQJJOLYY90l
GjcD4g081qiUYP.yTmIeJPT143L3w6ZvKCotHXyw5j6FIi56BJR89N0tPm4r
0OuH7gswwEiq.KpOZEll5PqitWkJfi08ibBAZRiNEyvllpmJUIotknZPpIBm
b396QbF2DXCtV0AiD389j1NW5g5bT5Z56E3ipr47owm7SnP.LQ+IEY7KKoME
nO69Z1f0sAb0+LOejzXATbd81YwkLboAfxJOXkavQzq8Mzm+lnrhO48sqROI
0YymNWOGRyu52e0+Ge6+yTB
-----------end_max5_patcher-----------

as I said earlier, this is where FTM and framelib have their raison d’être. In your first patch you are getting, I think, a phasing between your query and the size of the vectorsize. If you query at the begining you have long latency, if you query at the end you have a short one…

One approach to your thing could be to use framelib to cross the boundary, then do your ML stuff. I don’t know if that’ll be much better but at least you are almost certain that FL will be tight. Going in message land will most probably always have the same problem though… @jamesbradbury and @a.harker and @weefuzzy are active users and will be able to tell you if you swear less :slight_smile:

1 Like

That makes sense.

Yeah that’s what I’m thinking.

It will always have to touch the scheduler somewhere cuz I have to bang the fluid.buf()~ stuff, but I can hopefully minimize needless slop and jitter for that part of the patch.

For the most part, I’m still not doing this yet. Having a way to bias a query would be super handy, especially since I’m analyzing multiple time windows now (for the offline/buffer stuff).

I was thinking today that I do need to sit down and compare speeds for that stuff too, though I imagine part of the appeal of the knn stuff is that it pre-computes the distances, making querying/matching faster(?).

More than anything, I just need to hunker down and figure out how to do this “new school” and try things out.

I was thinking of trying to combine the knn stuff with dimensionality reduction/clustering where the clusters are “directly” mapped to the classifiers, and then do distance matching within each classifier. Could be an interesting way to leverage both of those approaches.

Ok, with @jamesbradbury’s help I’ve now got this:


I guess it’s one of these quantum measurement problems, in that it’s impossible to time things going from msp->Max without incurring scheduler slop.

So with the fl.solution~, I have zero slop from input to output if I time things using msp~, so with that I have to assume that the output of fl.tomax~ is also tight, and will carry on, happily to the fluid.buf()~ stuff with no more slop.

(I’ve got a bela mini on my desk at the moment (from backing the Trill Kickstarter) and part of me is imagining trying to get a stripped back version of some of this stuff working on that. (you can have a 2 sample i/o with measured 1ms from controller input to audio output!!))


----------begin_max5_patcher----------
3956.3oc4cs0aaibE9Y6eED5wENpyUNb5Sc2dIEnIaWzj1EEAEFTRik4FJRA
RJamtXyu8NWHoHk3kgVij8tMOHSQxgy46beNygJ+70WMaQ5Sh7Yd+duO4c0U
+70Wck9TpSbU42uZ1lvmVFGlqusYKS2rQjTL6Fy0JDOUnOeQzlnj0dxKq9y2
jtq3a7BK7de3SdYgEhp6ONJQrLcWhdPnxStMSjKelgEQoI215NHk2QxtMxmX
rnPSDfxyFsRO0oK9o2vfUyv1vhk2KogayDKKLHK.GLmQuwi3GLW9GH.OGbiG
V9o2+Y+DDkT87gpy8KWes5iabCeQxJB2sJJcblw3PEL.Tob+4ZjxT+gQt3.8
w6EIdx6Ujmq95CQgJcf2DGlr5zfsOe.XiPHEdoTpBvPIhUxa2B7DwiR53Hbm
Gd+Wm0IHfc.BV0sZtuhurUXPvr7n0Igwypo2NPIgATnDC7UnjBUeJAdOXD4N
L9lu5gn91iRrKPIGnvGAeFP4tMKDY8H0PcfGR0stIckn4McWZRwcgKEM0Y6C
y23M6t3zvh8fWM57n+q99fRDNJOgXLngHxQLE4jnIh5mRatTiYLIbidFm8sY
QRxxkVBa1lWjtIeBbV5rIy0Ff8f3J9BiMrJCzkFF1aT.cgQAIPgMt9KWDSeI
ue0hvj0ViSJuWbpeNCgRFT6SCFn+CM3BJGmjCNZvoHKYPfI7zqGObT1KsGtJ
lxu4bwsWs5jbwUyeNe93VrqnHMwdi.59DxxjL7BQ1shjvEwCqqLpS.ognwrv
jeCo5yytSfkwQK+r8NzomTVNUnjoEmX9qwPVDlSbycwiYMoTxIvSCjZszKeJ
4SBiX9Igw.zbzKx5NzqR7qd.OBAB..6wquCjoHjN7LO3hA26hmKWz7DbAgNI
CTJPunYDQ67g3e4VNoGcd.fvC31iz9sRGO1ImqKN.TiS+y.Nkjf7YXcJAPxy
JxoJQg1QOuKMaSnFj9ihdS1zPvKehCPz4IwAHgpWEHFetRbXh.kedvoQfdFg
YOlsa8VtcWQzFQl8hZqMasekBkvOP6c1mNh0b+qJn4LHgjgcTxOjCHJV7fHK
ORJu2isqlEtcaiSeUignXh+Tp9AEbS8ohRLmBVepLwCQUimVe1vLINKjfbWl
gHeptpSkqJKKYWTsDUKNKIIsfSAt7skKTSKeqtbCG9HS4QCP5+vMtBvr8LOo
lw53zkeVrpgJpT3sUjDkzrL8st7Jwcg6hKtskLDNmxov.ed0+55tOXkksuXm
xqqlsNKZUZhhjZIXTmtZxk9BLHk1DZ56HIbaGCVpqJ4R8bwbIj2kuHLSI2Js
dQUWrHMMt8kpGWr3thxKuMJI4.dZQ519uXVz56GXrKRkWbyPOa8UxucWh4p2
JUQJtMO7g1b6hv33Ri81O9mBShjQVDJqcMbA0Wz3A697kYowwsvq4JOzwUVI
U4WJdLZUw8sVAu5JxaOZakJ0rZo7pn0h7h1mqHbcd6yjW7ECSuwo1snzj91B
wlswp8ao0MHMVhxKxuO8w7xarRQqICX+th0zDuomyVm+.OnFuc01u8s+FG4t
r4H5v0G1TaDlwyOs5yZU7i8923BUabiZxhRjAidHL1KJwaStWTtWlXaZVgXk
mjeHZRFQIqDO0vuSYzjRWPOS9SqHLsixrvC1OeC1MeC0bDCGP83fM84npurL
LYPwLKKv3BEXqLnmhSc94pxH2KUN1mLqEOHqscPbWwag.sdtoBI+Jf49FoGs
IyXIWRFaoiCSolwlk8MHeE8Zfu9bbEPuftBLE15+W7D3eIUXILSmZ7JzQfdN
mL2iMQ8x98NRX1F8GzSze0r4kKS.M2qp8TRVUlAfLYfxbC5LI.zKNiL3zYjF
6VmwGCUbsRF4fLutxfZ+xSTsESOIcpwf55cyUyS2ksrhCTxi7ZiGYd1EQI0K
c6S0NKU2mUxzoRCLKoAzYjF7sjFjwh8fmIZfZIM3eF4CDKoA3YjFvSPVbtnA
jkz.tWZn7jUEeYlZI0qt0T9faCKJxhVrqvXF2rZRSZYt1UFk0woKBiOXErcs
V4q2CgIVGvMh77v0hiJDHXd.BSAX62OldqB3vEz0TnpxJcR4WxMhY48gQIe0
62op7lW3h7z3c6abyw2aX3yCwp9XTARSo4f3KJj0MnpTCd85dacjtfJ34AUL
xWu8vPJZtey+E3eiWvkq0ej.OSrNJWF2dZMADgeZxXy1tEbQ2dwZjZOJCNIT
hMK4D5eQgYQp7Fmv1nROMLZjgzKpNqI1lzAUrHYcw80qT1BIJ5jPKjWtkKAC
2OGX2A2MhhrTOL.38GBWVD8fXBnEBd9siXkKpt7PAgWNeyauOLOU5cBLeul5
3.+j5NoRYcWHmc4.9D6HK3I0ND0Aj.n43l+iAmVCZoui1KmyvCNLc0RNwwKY
f2LO09xQswBFNhaa6LgXVLSpWZgpkG8rmIrusyz9aJMakYiYQm1TaC6T0d1J
PV0FrQq1lJWLeoDjwgkuQI5DynT37pucL0BOIp0mYK0dpB+pGxvyD1EyD0lY
h3hYBayLQcvLQCrXlntvHkXiFQE4bZXxFiTJyEyjMxIxf1jHepostzcqGmZr
La8MDWW+XF0riGbcWxbZNLsQSlR61MF3zXYVM0tvbkXiiAhKTCrx0Lg0RMvQ
rSnMVUZ5qWMPL1W2XrPYb.3QKgEYdID63htFJVEa8.gpihVY0TefT1QnlXiC
3CRv4PWHXSbbldIMDBzzmys+JpLlODcT6R4JnXkWEH5bjbjZ8QiN07gXhUVA
xTjNJsYHPm27wWx05gHabYAcQFFPalIjKxO6.AdOXB5fjy41NQWjvm3tc2CO
+54P14vQkUQSQtHoJfsyzopvXUvyCHGGIHoVwNCrwseYuv23amZhSHaoM3Hz
FBoa.Bb.n9aNO9oMV8TWX0aGageNzVrKIA53SsonNGz82pY8ft99fN993t8t
+N89vt7VuIilVb8fBIsu4VTaYyGz8m7suWjryT+qptntMuYw56hhiWlFmdTy
tWUnrYlqV2X4U26mTkdjSfv.IeZNVlRKxWej7.Jsg1b4XfUChPIb.RcqDeDi
P0Go17Pr5HvACCset.PtYF.7..wbj7TpTJZNrvj0k8iMqQSEuMKU0JKUso9b
b8llFtqHccV3pnxV3.zZyQuoT0JSd0C6r3YajLznpwzTUrVX7tcKCOUAPMw0
iLvR9RaoPPMuOfAnAAliBH3NGVsTvmJmD08pW1Bybj4IcVDBklesPLgQgXMo
i33.t4HJD3yaQDyBWtT9zZMTLRp7o4PjJfnTWIGLRQrXygCkEHwqggAfAAli
jOEDp8XWrt0v3.BjomRIkRXLyvPbyihtece4xIcoh0zdVQRXooSnOCYrPB..
Ho8jppNtdb2FknbFIp0NvbDz2vgpL6PGKla0dbROf+8shDuODlj68AwlnEow
qlU4u+DMHdeXQwPFDMeCP9TiPhMa.BUausOt7IRP+v2VbqdXfeKYmZ8vNmFp
bpJ.gQOmv.ZvqvNdbCU67ybnVAZH6PCqtqiZ9DWFKjAi2ORcoCk2pzzkZHHI
Ckgsz7SO1pOFvdyzPpNRi9G+3eYHU45zjZqdphfq8u.QPpuwIoRyQ6xf2fs9
BYHXmq6W7rF5xN.pRNx3uWo7q4nrpzjF1NfBX9ZhF3SwPsc.TJfP7AsCBFIV
FwGBAlDu3Hehl+P4PoChAikA8wR6XMMvH9bd4Q.9f51+0urJKcsH4iZ0C2nh
q2k3nkSWMuWCxmYlv68Si4LiWVLuzom5TTraTOaAhf5f5GezyRodnjsJ8W20
Qin6Z6Paq7x6W+yNd7o6M9shDwCgNVW86Z7dh2sF6wQcBpUO.kGAcVdOkj0e
p90n8UDQ8VUeVZIUI0eqcpd7QtmzxeLR5XYHh6HSAXo919ONKzD5UEQ82xii
VU8yBfc5VGPMCE.yRWKG3.oWG.cu3qQmEWxudmX0zrC6BGcwq7O5lcIYKWOW
VzSKKxhOAp2oDjXeur1Mw3PEpKpqmuOckH2ZuhVljv.QeeV7ImB3I4BAblUr
9d8uehCQLc4E43flmAR6GhVVLNu5EWd9CperPJd0kswGVltUXe5F6qZMWuw0
ctXhWNl7GCWXOTrzqWWZNi5ewofRlR+hIm.c24SzwJUNuNN9X5Z0xvbV5rCH
TvL4BzglQPvP85IIkaqhKgz+byHarzELQyeL7Ag5G8ru5bN7zyJDn1RVm.tU
gYe9MIpexeditRFSuTGjZyRVck+q2Cf.MA6fp5AGQ0y4E+v4UzqcwOpKdvDq
jdWtUFs92NQS4mJeeOAfxWuCW7nPSWeaeI6O5.2UlsApBL3WYZZGl3Ms28fv
VXeztJrHVHCYZ1HuuKM8yyblJWTxmeNZH2z5SGT+05GsTr.BpCii8ARSzg2O
gym+JGuWBG4RZbvNUlSmaA23ipyxML9vNrrtV5g8Xyh8arhdVvMOZ7.4CQoN
wL4yl0j8ipV64kNYoXUpDimBcmRz5rFn09bprdFp1H.Nor4L3bb.q7HVfSi9
sI7I+5eYKsrzmR0q1qagUZO2KZNPr.Z3rdB61fy.biekbrYUdHLEwaGyPYwA
cMY052FBW2GEM5HhpNB33iFv6MKP0iY2z4QWvb.lpO+SSqps0gcRwl+NUZaQ
2ZzSeNO+Vy6A72EuST89KasYNFxJ2v589v3M8b4RBLK8wjISgi5a0gT3e7Kg
Sm.AHN0zf.LFFiLVaHnLxq6Iv2lIDOCJTy8pKEGzWkOg6It2K8rkTDNYxKf.
78MEIzGHINMqzmC4T2Si+CwpISer5reg0qs.TFwv0z2+VDGm93zYgHpo0WXA
v.cJ6.pTqbzdAixAffyA.P+ZD.5su3sowOCUj5pWPkYLQMc.TyffNg.2FlHh
+WQoiD74DWn39TfTY+aZmDhxigIS0mSSqC+sVSqucW113QRi6fT8I.SFlHJv
mqgIJf5iBrrybX08jIAR0uprRilRoh6zvxDKEQOL7dn1k0a8pR2SbflMipaH
NyhEUFnVm6kOQFZgWFRlU1b4R+Jb7fqL6xXOmKRVk+ZKV9dl7vdAOn2gYP.y
rieDe.urG9Yvw6eyKCqtHb6X8TeixB9tvhTu2opGvLmM+4Eh61EGWLss5R85
CwzbG+ZGkUtkGpOTCnTnYCM7wLr40avWZR56VlpATmIL4vJsfBXAlTLw0lNX
DGyCbJ+P8iR4qo2biGU0U6KSuLzPNGXxCWpxPJat.e..Ca2p6sIbr+nETDnj
75TCv04VvJ2CHqBCNg25gF1y+onrhu38mWm9rLmMuDi87+WLW+KW++rKtGvB
-----------end_max5_patcher-----------

Ok, perhaps I spoke too soon.

Again, I’m not sure if this is a measurement problem, or a timing problem, but if I put the framelib code in context I get much worse measured performance than with the vanilla sah~/delay~-based version:

(granted, I have to go via edge~ to measure things this way, which may add slop but the slop would presumably be the same for both versions)

What makes it even weirder is that if I measure the latency further down stream, with edge~ still triggering the start of timing, the results of both seems to be the same, or much more similar than what this shows here.

Also, I have no idea why this would be the case, but if I move the pink cable over and connect it to fl.tomax~, the timing measured in the fl.version~ gives me the exact results of the sah~ one (this could just be some threading shit I don’t understand):

In speaking to @jamesbradbury he did mention something about fl.tomax~ potentially having some slop in it. Don’t know if that’s still the case or something @a.harker worked out already.

Sadly the process needs to terminate in Max-land as the next objects down the line from here is fluid.bufdescriptors~, which need bangs to get going. So I can’t just stay “signal rate” (or framelib rate for that matter).

I think your assumptions were wrong in this sentence, and in that one:

The question is not how tight things are in msp-land (which is what framelib is in in effect) because we know things are sample accurate (in fl) in there anyway. The question is what is the tightest you will get in control-land.

You remember my analogy of the Ferarri to do a tractor’s job? You are not comparing speed of any car on a bumpy road. the problem is not the car, it is the road. In this case, the road is the precision of max messaging. FTM has hit that problem and solved it a certain way. Framelib took a subset of that problem and solved it another way. At the moment, your problem is within 2ms. You are very likely to not get better than that in any environment except if you do dedicated app for your bela… but I think you are talking academic problems here since a 2ms slop is much tighter than drumming. Actually, if you move as you play by more than 2 feet (which you do) you are within that slop with the sound’s airtime travel…

but if you want to make it faster, things to try in order of difficulty:

  • optimise your Max (lower SVS and IO (as cpu cost) queue size and speed (in the pref) etc)
  • try everything in framelib and see if you can actually hear a difference and see the cost in cpu
  • try Chuck which has a svs of 1 (everything is samplerate)
  • eventually, when you are convinced, learn or hire C++ coding people to make a custom app)

The latter loses all the advantages of a creative coding environment, but you get fast stuff the way you want. it is only the way you want though, so does not allow simple research on other means. If you are interested in such discussion, I recommend reading the Max list when Max 7 came out (or was it Max 6) when people said Max was bad because it took 5% cpu ‘doing nothing’ - at one point I don’t remember if it was David Z or Kit C who explained what is the overhead of creativity and flexibility.

I’m sure @weefuzzy and @a.harker will remember more. My take-home message is simple - if you can’t hear it, is it worth your time for now? This is a version of the very wise Knuth’s law of optimisation. Actually this article is a good one: https://blog.ippon.tech/5-laws-every-developer-should-know/

1 Like

Don’t have time right now for all the details, but basically my thoughts would be:

1 - expect CPU timings to have some variance - you are on a general purpose machine, and not a true realtime computer with proper interrupt priority or guaranteed time constraints - probably not worth worrying too much about the variance, in comparison to the overall costs.

2 - if you really care about timing you do everything in the MSP thread - every time you switch threads in Max you are basically giving up on tight timing - there is no such thing as maintaining tight timing (although you can maintain order). fl.tomax~ simply calls schedule - there’s no special slop here - just the slop of moving between the threads - this will always happen, regardless of the technology. I’m not 100% sure what the framelib stuff is supposed to do in this patch, but it doesn’t look like the right thing to be doing to me (grabbing single samples at specific times).

2 Likes

Hehe, I just went real rabbit-hole trying to iron out every little bit of slop I could.

Having +/- 2ms isn’t a big deal. The problem potentially comes where there are multiple of these along the whole chain, which can start to add up to a perceivable amount.

(I’ve been going with 512samples (11ms) as my limit in terms of “feeling” it. It feels real tight when I’m limited to that amount of latency, but since I’m adding additional things (the melband stuff, compensation, ML, etc…) each of these is coming with another time cost, so I’ve cut the analysis down to 256 (6ms) so the rest of the shit can happen while still keeping it around 10ms overall).

An ideal solution that wouldn’t involve going too crazy with solutions would be to stay completely in framelib. I think @jamesbradbury has all the spectral moments worked out there. Don’t know if there’s any plan for more bits of flucoma/framelib to overlap (i.e. having more of the descriptors present in framelib-land), but that would certainly solve the ‘tightness/speed’ stuff “simply”.

I guess as a final question on this specific area, is using framelib in this context faster even though cpuclock says it’s slower?

As I have already learned from @a.harker you want to use fl.timer~ or fl.framedelta~ to measure timing inside of a network rather than on the outside.

If I just count~ + -~ on the outside, I can confirm that it takes exactly 256 samples to go through the framelib system (with a fl.chain~ set to 256 samples). It was just a matter of moving from framelib back to the scheduler, if that incurs the same slop/timing stuff as going from msp~ to scheduler. If so, I can just keep the older sah~ approach since it means no (extra) dependencies for that part of the patch.

Two things.

There are built-in moments calculations in framelib, but you need a bit of extra code to convert some of the results to the correct units (James’s versions were I believe working from scratch).

There is a difference between the speed of the processing in framelib (time taken on the CPU), the slop sending it back to the scheduler, and the delay in doing the calculation (which is zero, although you have the latency of collecting the samples). So, depending on what you will do with that data different things matter. Time in a real-time audio system is largely a concept, rather than a reality which makes this stuff all a lot harder to think about, because humans think about now whereas the computer has other ways of tracking time (such as sample position, time tags) which do not relate to “clock” time.

1 Like