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.
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,
When you run the other examples (
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!)
@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… 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
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 (?)
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:
you have, my friend, found something dirty in the closet… a very specific case but @weefuzzy is on the case!
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.