flucoma / flucoma-core

Core algorithms and objects for the Fluid Corpus Manipulation Library
BSD 3-Clause "New" or "Revised" License
79 stars 16 forks source link

`fluid.bufampslice~` not working correctly (when using `@numframes`) #259

Closed rconstanzo closed 8 months ago

rconstanzo commented 1 year ago

Porting this over here from the thread I made on the Discourse.

So I’m building a cascading onset detection thing using fluid.bufonsetslice~ followed by fluid.bufampslice~ and when testing things in context, I’m noticing that fluid.bufampslice~ is rarely returning valid values when I use the @numframes attribute.

In this example if I analyze the whole buffer (jongly.aif) I get a bunch of onsets detected (notably not including the first onset), but the moment I add @numframes 1024 I don’t get any onsets at all anymore. Only when I change @numframes to a huge number (8192) do I start getting onsets again.

It seems like this is broken to me?

The only thing I can think of is there’s some window being applied when using @numframes, but even with that, I would think that adding a @startframe offset would compensate for that, but still nothing.

b167370d3686ff8fa697be85da0b7dd3cf7db232

----------begin_max5_patcher----------
1584.3oc0Y0raaiCD9rySAWgdzUf+JRsW1dbeGVTTHaSYqTYICI53jTz9ruC
IkxOM1wzQRF6lCgfzTb32Lbl4aH+wMyhVTeutMB8mn+AMa1OtY1L2P1Al00e
Vz1r6WVl05lVT09sKzMQy8+DzqnpTab+FoavhUtYVu31OyT8ybWVS1VsQ27M
cU1hRscJ3mWk58l9kg1MpeHyC6z98WTzbTzhrp0Qnu9zhZVtonZ82ZzKM9YI
37X7bDUxrMBrqCMFi9p8S94M2X+27.A6x5sa0UldLXz26jRDOFYZd.spHOW2
.S.AHH2hu1XTcU4CnC0MeuEcnvrAstXcVkoXIzqZU8g1+pe0JKpzKq2W4VRd
OhZzsvBlYJpq91qlAqaF40Ul7rk5WpwWreQmJkDpgII5EqWawitulZUWGylf
ewjq.b5Vm+VWdmFPVVzoMGLpy.fkwBngSr8RwVywq15sEqbqIaDMRrXTUswt
ePG1nq7FlrprxGdzNFbfzfpyQlMZzh8VC4QMLzAYXNqYPbcLCBVp0.HncNGt
FdxH6VPiQs0nsYUO.J6VXO+GQCQ2vuN5FBVHhkDIOUjxUXYBkqliHJVLmkR3
ILEmR3JlzNXpS+8QUbP.h1r052n3HDElGezfpzinXXQGUCPNYfy2KfImKcQJ
YhQHf4IAnUKFcVWIZnZ.xXpAnJmFf.NGfOBmNIZ.EIkFrAFOEvKgXgm2LO5v
iiSSBEdzzI.dTLaBgGEyUACO0T.O9XX8pzGfc3aPmAs.UDJkNpL5xns4nrAT
2Jr93mGoLhOdjyYb7CDgo7fMjISggTplvyoGxtSmW2rEcac0ZfV0bTaYwRcK
5Sz9g5+lMEqVoqNYB4ioO3io9PIowoLdZJjTMg.LSRS.EBywLgjJGj54118A
edlkd4knLlHtqPE648DAFqHXHUoTf4fZP.JfDYZJlB8YBkP7z5mWTpehlSd4
9hUw8F+eEeaazHRqiDir9vHScG8Ys+rzCCgcGkdcX2wA+MaTElu.Dwf3ucJM
jI66ZTdQSqwS78cqj3bZFxIxefeG58Xk2ewEaQH6P73BxVishoLTYgA1SnEE
FjNqorP2ftcOfb33wBMpMKWOL3mbwvm6okyHtbjDJcP3ewdiotJzvGD9HF93
72tg2P2QVuqZN93xFvGLAJIlVVzZBMYI4R4r5V7.JLAJK6sEhImFR5ti3tKx
A8Ixbjm4RX3WMA0jwDNyLgvlBVeeFQEAyY+RoBcNxd8HzS1ikLL.dQ2Io3Ze
kjcXcbtRxSXLerzyzCQBlcazkC0ffomBmXRpTweQc+pmKaGOj3rh7fiWegvN
urNyDjYVk3iM6BMQXCiA6kkDhxUWyrP8NucbplzjPYa24NX+KzWZq22rT+js
+K4YsF.r61uCwdt2p5CUHlBFosr9P2uSoXwyC3lheHfN4lFc6l5xUPbVned9
yC.+Nn2chGHau1rA8xxG+Pranb9D42ontauRg8YNF662QAmqQxDfMMTVhPwh
AG8jDIzj.0x.MRYBN1xASZa.hJvuA4rg5ZfMEmBSQPRRsMbnLmXTBX.fJKRR
RsKlDS.t+HIPWGFTJgRchQJgDHriRYTNLkTNm.SgfwV9dHacRPdCnUQs6MHK
o6aIjjD6zIThPY2sTtsl6vsZGKVIabSu6yDPfsU5uyrQzUuh3+Bj5nL9Dwpi
vwiNqtADJ4o2uy4g++zPKO+XRibnEN6XGTE7AcPMyXZtfao4imeyJndZhdib
zGyqM0CXHFlSYHR69ycSMGmUma8blye6Q1cquc7Wqg7mK61M8OfN54WKckt0
TT4d4jWLIfbNhbBiPvBJ.43NggvCTRpqljdZUdWYYqbc3hhGDrrY+GAYwCRE
95YU2rR67CHWCg+5I816Z9ocCdP6lda26tYruWp0+XbUD12f775A4HXuY3qk
jruL2URRpqljjAcdUMVhhbtSiigfRtZZuP71Yomxae5ctImHJ2vhqDh9cLNw
HBL69fMiAHmwIiaPYGljDSgIZGgJx6edwyZKa2t6zMsceuSt.C1aqcSWM20s
nx2U351nuqne99QxZ.VjFfB49F+SVcehmjez1ZPvU.AXOvADChzwN197Vs65
dNMGI5a94M+aWnL7.
-----------end_max5_patcher-----------
rconstanzo commented 1 year ago

In thinking about this a bit more I remember way way back when I was first wanting to make sense of fluid.ampslice~ that there was something about the envelope followers getting pulled towards -INF with synthetic signals so normal-ish thresholds would take a really long time to respond. I don’t know what change was made but it was eventually addressed in a fluid.ampslice~ update and I’ve been using it since. Perhaps this wasn’t ported over to the offline .buf version?

This would make sense since when analyzing the whole buffer that it would behave reasonably, but when doing isolated bits it doesn’t have enough time to respond. This would also explain why the first onset is being missed in jongly when analyzing the whole buffer.

tremblap commented 8 months ago

I think it is fixed now, but please confirm

rconstanzo commented 8 months ago

Nope, still no joy. And definitely doesn't behave the same in RT/NRT:

Screenshot 2024-02-23 at 5 37 04 PM

<pre><code>
----------begin_max5_patcher----------
1472.3oc0Z0zjahCD8rmeEpnxoTNrHgP.6obb2K6gT41VakRCHrUJrfEIlOR
pL+1WgDNlIi8LXrrM6EnTiLs5W28qaIy2uYg2sUOvjdfeG72fEK99MKVXD0I
XQ+3EdanOjURklo4kUsYCSn7VZelh8fxHOxG7mJfn5dPAWjKATAnRHYpkfaa
U.0ZF38B8be+VohJqzBdiToEx19FK4BVVUqv7ZC6EV2vjZsRU7JwWd1Lh6mQ
QkPInaXlEyevJuio3YzsuzZpJaMWr5KMrLk0bwHjevRPDLp6FJJn6Fg3G.9m
AuxBZl4UB6kIZ2vEkLk7WDV0p1JMnWJO2rVpt8qeHF4M3cJ4ey7NQZU1I8G2
bS2kkmnG.6CxVSEqXZbkKApJPBLEsWXE8lvJZpvZJjzAj3.yMHL0L5LAqPGB
qaXRIcE6kvZPJYqP6xQ8XMyZrdd+zp1CTjXivvvjtag13Lz.j3YVMZuVMbOV
cfmCMugwHGo4EGcNLORpmCSJP9fO84dJICyilYp7d5ixWMu3ni5goXCVDa73
vnvyXTOAeAHSf25qApRfFwTZSUB345ooAgxIxSOcnM.QrLzVrMH8LRTSBuDX
qOP0vWsh0rCUAz1bdEfKzz1e5y+1e8oOeoItwjXS8PSnKBhNmQvnK.ucLINz
GOMpsHrkSyRsYaMvATaQgSgZSvtW+ieg8oZnBYIUw.aj.IcScISNMqsuSHDw
jYA6GcPyENZyE5xBUuCcZVWnMvN0OxM9RmVEVpnMphFc9J3cPcKy513NIqsO
xEBCcTnKNwkUkC8AZFNffcmlCLuh43pwQ8cc1Ww3r1CJ9Rvk8An+IENfibKQ
FdRDY5MBppDGzPLA8upwjDNvXP3sWOQZJLdWnTWFnh07ElfdaoYgE3NF6hxV
dt+ssEnRtTcPbv7vw3Ts43wHW4Ti7NC1ptvjrjmwdB7QYUaSFC70JwJcsJvG
0qHCkmDzsGKvGKnRcQsM0s0fvcixqtW.BSzRjkU22+bDJHZm.yTrhz4fq08F
stpLWm3qGWTrSf94ZfwrbJYhUp0cMWheUtmWltsbjLvD6wKXy451czwDlh1i
6g37BN.XL1WW2m3mj.RQ5qduY+k3IwCEhLwpDylDggNKjEdFvDXfFSBPGAlf
lDl.SHCwDnivjPzTvD12xoYO8J0TIVR2nXKE71qGyhcOUOQQt2AFXcaO24cb
tFxvnU6FNcfmANoplk76X9xrpZ1SSuzIjX2Ccr8l0jLAfmpMAcXQi5R5iOss
9vAMVIekn6XHFgYS56B1DzFmNk80rGl3TmWmbPQx+WTDbmKXLQcvXC2F1xZ3
fRgwNzAnaQof07ynN68G8o7hCF.VTVQUiK9y1jJLwdKL1QQfSJoipTMs7QPH
1MQav4fnuWozPLzV6h.sG9YfqN+.m2X9zgf15Q..1iXvg.Pz0G.1w2LB.HMv
w..Y9..iKIX6Au3NHH95CACpm7JHPReOFNOKHYFf.CpfNBHv4LgoWeHXMe05
Z8Oung8uuMD377.RvLnXPYUUyHb+tlFj.u919OOrFu29O7NJ0w1+n4.MJxzD
6u7QsXVscxeNnXORpdqt+OWeIX25MmIUbgYK+ClT25oaR6E3GqlHoWLMEOBM
gItPSviPS8SZMOOmIF54qZxYMGNx1oKl3wtVfm1ZIXNALAyGfIJcFALiZwbo
.lj4DvjLi.l34DvDOi.FxbBXHyHfIZNALQyHfAOm.F7LBXFUeLOmT7Rp5nP8
jfuT0mnGXL8Erc8cRZBFNFMEre78zLxPzUS0X30S0IWps.fGUUnHWnoQQqef
LE3EP03qVPT54fYZTYNmEMOllrPQmCGc5X0rys4QQQd0PaH7bDae7a+ZuJ1d
HPz556XMx9esQmdanesxL8jklgbgcHwLrgcGe67M+oadzlr0bEKS01X+5Cen
+iu2aSkVwhVdObqsVsJMmuV2Wpnrt+aKzbLb27ia9ObvyvUM
-----------end_max5_patcher-----------
</code></pre>
tremblap commented 8 months ago

ok you have found a VERY TINY edge case :) to see it work ok, use this patch to add a single silence at the beginning :)

(there is a fix, this is just a teaser)


----------begin_max5_patcher----------
500.3ocuUEraiBCD8L7UX4yrQ.Ig5rm5+wpUUFxPVGYrQ1l1TU09su1iglzs
rsoQs8.X4wd7yu48X3gzDZs9.XojeR9EII4gzjDLTHPx37DZG+PijawsQUvc
558zr3RN3fCC2JGDaWTOz1n650V3Ix0V8foAHBE45sf0ITbmPqH60pcRvFCZ
cbiq0v6.RwzYJEJnQOnvCtbLnZnSO3jfydZzdtq4OB0taLPiKxhh7UUKxyHE
kkggR1lvvx0KxI+dLq3A4tuGhoPoY9mmWVrEYjmk+nXC8H9B0D7EgXOllFdk
cl0sNvZ46fWU3p4pczYIYwaQxkr.sVwlHmmokuIEmkdrYoW4EPu+isvaHZAy
SAS.p62ufKZoWrlVkiC4r2mvsRM2EDVr.OK6u5KWbaj.2H02kQr7td6QO9Yq
zrhSDZec3RU5puKkd5y6hOrJyJQ1wPodyUeFRb0mlBycNyf3i+g5njsdIpeq
yuT8Km9LHgtkNvbCn30RLq7w0BWRLkW1Z8cKBHhXe2+4WAHiBweYkI1Ye79N
c8HG4zIs6OcSahaZ1p+YiD6aCopy.opWATrVx66uEL1wMiX38S60n7vxvoBU
b5ZbpAtULs+XDtw6lbdqzfAuWzCUqnwT0aAixaGi5nmcdHQupxK21ddjHnkN
8wz+BnEVi+O
-----------end_max5_patcher-----------
rconstanzo commented 8 months ago

Ah nice!

The patch is kind of confusing as to what's happening and/or what's being fixed, but it's good to know that it is a trackable thing.

Does it need to have a single sample of silence for it to start the envelope follower(s) properly? bang-ing your patch makes the first onset work, but not the next ones.

I first found this when working with audio recorded in realtime as I couldn't get it to find onsets I knew were there, then just made a test example with jongly, so did get it happening with all sorts of audio.

tremblap commented 8 months ago

and it was true for all slicers. now that makes me suspicious so I'll push a PR for @weefuzzy and @AlexHarker to confirm I am right in considering the initial value of not 0 as a bug.

tremblap commented 8 months ago

it needs a single silence sample in NRT indeed, to start. I think it is a bug (I'm 99% certain) and I am pushing a fix. I can send 3 binaries for MacOS if you want to roadtest the fix in the meantime

rconstanzo commented 8 months ago

Yeah, happy to have a test.

I guess since the other slicers are doing windows, a single sample isn't as critical? As in, fluid.bufonsetslice~ would find onsets here, just not be as accurate in terms of reporting where they are.

tremblap commented 8 months ago

you can have a road test with the others too, I'm compiling it all FAT for you and will put on the discourse thread so more can try it.

rconstanzo commented 8 months ago

Testing looks all good here!