Fluid.bufonsetslice broken in alpha08?

Breaking this out into its own thread as to not clog the alpha08 release thread.

When using the current version of fluid.bufonsetslice~ (and potentially other buf slicers with the new changes in alpha08) values returned are incorrect in weird ways.

----------begin_max5_patcher----------
1407.3oc2a0sbiZCE9Z6mBMbcpGIgP.8llK66PmNYvXYG1ECd.QRZ1YyydQ+
PhyFrPNVBm1bgYrrLG88c9+P7OVtHXc8Sr1.vuC9KvhE+X4hExkDKrP+9EA6
ydJuLqUtsf7586YU7faTeFm8DWtd3JPQUdcSCKmCZXsck71+XXWkEUr75tJ4
Vw5EOzuq96TFunt5tQ2w15JdawyL4ZQqf5kq51W2wKYb4IBdzlqx1K2bvexJ
efwKxyFNAGx342WTs6Nw4Sg2PHs+VBnQjUQ2.PIDw6h5WC72GcK2lkKukH8Z
EajBnd829sHTvamnhpgCDRr1OWtT7xMWHqhWA3rVNnstqIuWQ8Ug5PgBxBgw
xKJpKDcFTGz6TGZE3wlBNCTW0Jt8yBwDmjHnBbhxjBet7BI0Y7x5NNutJXT7
MHY0R7+4.Sc7CVmUsK30C6X.LR5zDJQFlL75qekiwR7aDUSOIxYM2wpxVWxN
lhuXbtm01lsi8A8edIKqor9wyjArB8To4ej7UgOvnve7nC3OADqXO1eG+.BK
qy1HUX9QGGqBHlXBjgtyd8DfjCVCJGGgXiH7lIzknjXIxfDUV.gG6IgYRfuM
WUQ3A76aXr1r8GJOmn8tv1VyGHpJlNFZTuG6Li6oHjGqupzAVcAgLRGz4hNp
qzVGAtGqoRLhfwFgZjyfpexPgfH3QEmXNGENcVxQcxXan9iq3uyL.WgndG0E
qnh3gXblTrvu3kdjjDYsdMDcs0qX+oVGHBcB5TiZUruSPen96rWFMu030Tav
NEq6m.YLBDd7jwgNGReHyi0.RqgFvCzXMT334AOSj5.NYAguBGhQ3PcFb7ZK
L1kefbsiiD4svHC7fNLB1nRMx2gQV2scKq48AR9LfeaeWQR3aqc.IVQCQFqv
CGNaDvqgclG3STU8QL1LKFNWv+0nTyC5Uy.DEZLBM5q9TYvptzoQvoCoE8+t
oxPknlfnSOTlT+22JJkl.WARO9xnyAOzkcvEGqL.j1AJy.R5IFLE02Cl54Rv
tl5tCmo26jirAqJjhp6pAhMMyFBw2vjCJ.EdpyMUG4Dk9DgCMhTGlapa+ZVy
mPuMca4ZDgouYgdR.gulUc087ITpgSMuwgq1pcSIpbPFafy6lwGXru+BnnZS
Q9oZ0AYNgqE9rQp1TSLWkI9KdqCZEWHN0hVGtpifXGimw4M.QsTsmo4rLNrk
iOOLVpQSLV7Lh9Eu9ogmEPHcZ8J8ZpVGpR1n2pCJOVWRkJ8ShwwwP7cmAaK6
J1rpG4pGjaYOveAbqlAFXBvsa2x6+XdON5abBg6cRkWts+PI+Nkrpc76AHe9
rjRTzl1L5TQ4bFgI7v6JbYozgTxQNBnQRSKjop922wqAi30+e.bpFkkYbx3M
E4iguo6IVd2jU8+K+O1HORh0eOpUOjGM.FdF5f2NTaXs8F3xm70QaR7PXEaZ
Tl0ZIgrPRhofbzlpa1vjjDbFDMbbQi7unQoiKZ7EI5vTaPcpOHbqDcHxGDtc
nl3EBOwBQScfqjTPnovnKDTjM5wDWHI5rIo34RR1.IWnkPykbfyjfv1HGjKr
Ef13Ho81tbIAsQRWLlvmgjbbXe7YPmWCQGOtnQy.gG6kjc135G5DWRqxnCcg
jhtZ1uRQecresC0dwHxNT6EWG6DMcbQimABm5i5D+kpOOgnibfuTpM05PbQy
c1.oHuzamMRlP8g0q3whLo0q77coUOPBsI5qSTj1jLa33bY4tDGW7TdANI2k
UXxErG1pt8cQKfHaZtffckjPmcLD0joxNb3AVSqdyRYDrO6a0RuujajusnR8
V4nsCZXOTLrepbkrl76K3rbdWi52IyST0HgC1W26GW0Unck6QWuHkS0S7apo
8f9mAib3eK+4x+EvQlU4b
-----------end_max5_patcher-----------

Also, even the one(s) that are correct, are off by a value greater than the hopsize.

So if you send the source onesample message, you get 4672 as the returned position, which is way more samples off than the current analysis hopsize (in this case, 32).

When you run the other examples (source twosamples, source threesamples) you get values that are similar in amount of ‘offness’ (between 320 and 328 samples off).

I would have expected +/- the hopsize as the window of accuracy here.

Is this the expected behavior?

We’re investigating. Diracs are test signals so bad in certain ways, and good in others. The multiple similar values reported is definitely a bug. the early reporting by more than one window is complicated (filter size vs threshold)

Yeah that was my concern there. Like if using this to take files that have known transients in them, but just need trimming up at the start.

btw did you try the didactic patch in the helpfile? It does the same task but rightly, so we are working hard to see why it works in one setting and not in the other!

(I will test it shortly. My laptop is presently sweating its way through the 3k+ sample library now that the memory hole is fixed!)

1 Like

@jamesbradbury might have some CLI magic for such batch processing (now that the code gives parity results between CCEs)

Let me show you CLI scripts in Python…:slight_smile: No more of this single threaded slowness!

I am working on stripping redundant files out of a 25000 file database and I’m very happy to be not doing it in Max land.

I’ve got a deferlow loop going, so it isn’t jamming up the main thread, but I just didn’t want to open/close other patches and risk a crash 50% through a long process.

But yeah, testing the help file it all works fine (though again, always seemingly more than a hop out, but I could just be misunderstanding what is supposed to be happening here). The settings for threshold and such are different, so perhaps it works better in those circumstances/settings where as my example is a bit more brutal/plain.

From what it looks like, even if a (non-digital silence) “faux” onset is detected at 0., it will still actually trigger an onset regardless of the minslicelength setting.

I think the problem in this patch (accuracy of detected spikes notwithstanding) is that your uzi is counting from 1 not 0, hence you’re not seeing the correct values. Change uzi in the patch for uzi 0 0 and all is well (?)

2 Likes

Indeed. That sorts that bit out, and also explains the doubled values.

There is still the accuracy issue with a tiny hop size seeming too big.

Also, it does look like having an onset that falls within the minslicelength does in fact lock out the first “real” onset (even with digital silence at the start).

Look at the source onesample version of it with a much earlier first onset:


----------begin_max5_patcher----------
1386.3ocyasrbihCEcs8WgJV61kdg.lMSVN+CS0UWXrri5FCt.QRlzUmu8Aj
.GmXvVDjHIKLExBNbtuuWh+8xEdaxehW5A9Kv+BVr32KWrPsTyBKZOeg2g3m
RRiKUayKI+vAdlzak96j7mjp0IqAhrj7hBdhDTvKqRkk+c2tREY7j7pL0Vws
KdLVlbuHa+OZtD8i.AxVCWAX9z09q.nPZyY90qA9d6EsKOSlEefqv7e3oOvk
hjXuy91cwIpuE0tVV0AQVJWVd9hhspaP9le9Mej2q6LuR1sU3Y2yRwyp6I1e
MrY0+rbYyGqlnLCuFH4kRPYdUQRsZ3JBFDoQTfvX0AsfgfbqfA9oIXPqAOVH
jbPdVYCpCKXBBCaDE3PsACdFjKzHmKW1TIk4YcvnwP9eG4ZN6sINau2IF1mT
wW4GQThCLs6ySWRuT7XbQsbRxK9AOKdSJ+bNcN8C5m9nO.OOvKKi2yuP+mjx
iKRyebPIfQrmo7Y7Ue133zO8w8PQj8nXF+w5a4ELLMOdqRMNUcbfNFY30IYO
lwjHmSRIXCH85Lb0Mzknv.EyfTchgF27wQyv9oI1hlq532.48EbdY7giouFK
ebVtsrEwzg4wvQa5RlAuyN59XtUHKVe.gFOYYyFYyyZ0rShqQJNhfAimp91i
pSM6BBhfmUMhkyufmi3RnZRz72fBAQSUI5CFIJB5hOM5vvP6EeZpJ1vPe2oW
InYQuhsgZsSPzlbMZ7ZUr8zpCP1i4+h+Ru4bthcJtsABzMh.Q5wubfDoPqSo
KxqLrFpiOvvwymfYhOWj5X3h4NQG53oCydzwRse3n7Cz4J+vTihzIFzQQniO
2.124QQ1TsaGu3swQ.9WKD5t5VWTz2Ty.ZfVL3iFu.fLeBfSQcrM8o5h9njw
Se3rQ+SAorM60SzCQFeCpnnuNUFg0MXy7gNHhl+W8ApvTrlhXev4oDMCMk9M
z5OXqYAAZUqRC6O9VtoLmmP54Tv9h7piCyvaMGErtBIVa6JP70GjRezj57fQ
Rf.HlbKY5VsoZ8IBSF8Hin1LqS0gM7hqp2tc+1sLByLwBcriy08cpT8r..Av
aNHvtilpgiz0UQG+vTFvTlXwR+47e8BPjsUjbk4ioSmZfequtGT862Xb8Ef+
BM3HshifibQeAte9B64xXor.zToT40iEa3bsIAJMZ33KMFwrmMrkzqXByA5U
2mcsqFXy7VMIhcaAS5TPgAiV459Ts6RqDaWWyb8aXMsl3u.tqUBzII.2samr
9qk0rqtsHDt10Uc3t5Ge00jxy1KuG3Csya4ITK29HsJYOIViKdk3iULIgQOy
S.0St5l6ttP12HB8L0s2ddC1fm5AUccdxkEhDi4G71DTgg5+oj28eth5AsY8
2xZ8qvokVcuSP.5zi5VdYsEdrTTGC70MUaQUW0x26UvZJPL88v43flKbfyDP
XSvAYAfnlH5ZlDwYaJuXKuX3nKFyQeSHYX+PCmNzHSfF4DnuIqC5m0nYf0A8
y54.ZV+POGlYLmXgSMAZea3FSL.IB0BHotI3awIqDrkYfMC0V.cKgG0Jg0MJ
ZKyFHYRFDpMjdTiPhXKibjIbBMUjLwwkxbQjRif12EIEiBLgz1v1LxjfUPaD
rxD+MhM7rI3Osz5Jn+bRqaFzNoNJyD3No5QBbDPOcjLU9NMjLw4mXENwlMj7
mMjBM.IajVmXRny2U1okJl0HneW.WaElwHVG4Beci5OFCcAqMCZhSXsQQCht
vfVOYp3iGefWT1taEHdGh+Yt5AKbk5TQl9T0.u8J3OH51OSsRbQx8BIOQVUn
+oq7DSOTXuC40TLqRzJfqoWMjpo507ybo7X6ulE0v+V9mk+e0dOFM
-----------end_max5_patcher-----------

you have, my friend, found something dirty in the closet… a very specific case but @weefuzzy is on the case!

1 Like

Any news/info on the dirty clothes in the closet here?

Still working on it. Nothing to be worried about except for the first hopSize or two, so you can still use the tools. It is just a little complicated to explain here.

1 Like