Fluid.bufampslice~ not working correctly (when using numframes)

rodrigo.constanzo · July 11, 2023, 10:06pm

Putting this on here (rather than directly onto github) as I’m not entirely sure if I"m overlooking something silly.

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.


----------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-----------

rodrigo.constanzo · July 12, 2023, 12:11am

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.

rodrigo.constanzo · August 8, 2023, 12:26pm

(turned this into an issue on the git)

rodrigo.constanzo · November 19, 2023, 9:50am

Bumping this to see if there’s any bigbrain workaround to this as it’s essentially impossible to get sample-accurate slices on buffers if you use @startframe/@numframes to analyze anything other than the whole buffer (not to mention the first onset doesn’t exist in fluid.bufampslice~-land anyways).

I thought about just querying ~100ms+ before the point I’m actually interested in to let the (presumably laggy) envelope followers “catch up”, then analyzing a bunch more after that point, and then ignoring any values returned outside of the window I actually want.

As in, if I want to analyze for onsets starting at @startframe 5000 with @numframes 5000 I would instead use @startframe 1000 and @numframes 50000 and then ignore any onsets found outside of samples 5000-10000.

This obviously runs into a bunch of issues near the start/end of the file as this “extension” approach can’t go beyond the start/end of the file, and would either throw an error, or not return correct values.

I don’t really know the code structure enough to read through the algorithm, but I have a very strong hunch that whatever stuff was added to make the realtime version work from digital silence was never migrated over to the buf-based version of ampslice.

tremblap · February 27, 2024, 3:51pm

ok I think I found it. It was “fun” and “interesting”

Can anyone on Max try these (unsigned) binaries? SC people I can also compile for MacOS easily. It will change only the first sample in the buf versions of unipolar slicers (bufampslice, bufonsetslice, bufnoveltyslice)

Archive.zip (594.7 KB)

tremblap · February 27, 2024, 4:28pm

oh and @rodrigo.constanzo can you please road-test the RT versions too? They behave as I think they should, but the more the merrier.

Archive.zip (443.1 KB)

rodrigo.constanzo · February 27, 2024, 5:15pm

Working perfectly!

NRT shows the right values and catches everything, including that first onset in jongly.aif:

Long lost friend, it has been so long since I see you…

And the RT versions work the same (as far as my testing can tell).