Closed rconstanzo closed 8 months 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.
I think it is fixed now, but please confirm
Nope, still no joy. And definitely doesn't behave the same in RT/NRT:
<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>
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-----------
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.
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.
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
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.
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.
Testing looks all good here!
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 byfluid.bufampslice~
and when testing things in context, I’m noticing thatfluid.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.