Beat slicing
I've spent most of the afternoon playing around with slice~ (but I can't get it to produce useful results - either too few or way too many slices, and the docs don't help), and then seeing if I can get my head around using peek~ to find useful thresholds to put markers (umm, my brain is going duhhh). I was thinking along the lines of - if the sample value remains below a certain threshold for a specific period of time, then consider it as a gap and store the location (samps converted to ms). But of course that picks up all kinds of useless places, and I suspect that I should perhaps be looking at attacks instead (no idea about that!) Either that or I'm not using useful threshold and time values.
And I've been using uzi to drive peek~ thru the buffer~, and I suspect that it's actually going too fast to pick up all of the values.
I've had a look on maxobjects but haven't found anything other than slice~ (and p.decimator, which does something different from what I want)
So - does anyone know of any 3POs that will slice up a sample file of (percussive) sounds into segments (all I need is the millisecond start times of where sounds start) or has built something like this and would be willing to share the approach?
thanks
David
Have you considered visiting the site www.maxobjects.com and looking around there? It's a great source of information about 3PO - the best, in my view.
Hi David, I've been working on a related project recently.
I have tried Uzi before and it does not work for this task. Metro can run through your file at a fairly quick rate if you give it a small value, something like 0.0001, remember to have small vector sizes and audio on. At the moment I am just looking for peaks in the file, as opposed to transients (however this isn't particularly difficult to extend). Essentially you are driving a counter which is the sample index, whenever you hit a peak e.g. > threshold on the output of peek~ you stick the sample index in a coll which you can refer to when driving the playback. It is part of a pretty dense patch, but I can isolate it if needed.
There was also a guy from SARC who made an object based on a library of descriptors of some sort,his username is something like crx3242 and he posts quite regularly I think.
"And I've been using uzi to drive peek~ thru the buffer~, and I suspect that it's actually going too fast to pick up all of the values."
"I have tried Uzi before and it does not work for this task"
hm- what do you mean? could you explain what problems you ran into using uzi?
from my experience it's just fine for this.
@david - i had posted a max-only version of the slice~ object some time ago, so people could see how it works internally and change some more parameters or adjust the algorithm to their needs.
the code was here:
https://cycling74.com/forums/more-buffer-analyse
but it disappeared in the void... (not the only blank space in the archive btw)
if there is interest i could search my old hard disk to see if i find a copy and repost.
volker.
@gregory - maxobjects was (and is always) the first place I looked (look)
@volker - I'd be interested to see that if it's not too much trouble. The thing I've found with uzi is that it's as if it goes _too fast and samples get missed. I replaced uzi with stephan's ST.lowzi and got completely different results from the same buffer!
@mike. Mmm, small vector sizes - maybe that's why I got different results with a "slow uzi" . Unfortunately I can't go with real small vectors as the overall patch is cpu hungry, and I've had to increase sizes to lower the cpu usage. Peaks would be easier to look for, I was trying to find low values (ie when the overall level drops below a threshold for a period of time), but that doesn't really work as of course the waveform is always dropping below a threshold. I suppose finding peaks and then subtracting a number of samples could get you roughly back before the start of an attack. Hmm.
David
i have also had a lot of trouble with uzi/peek/buffer/poke/buffer things... ugly experience.
count~and index~ is just fine imo.
Just had a play with count~ & index~, and you're right - much smoother. next I need to figure out just what it is I'm looking for!
That beat slicer thing mentioned earlier is here: http://registeringdomainnamesismorefunthandoingrealwork.com/Mpeg7Encoder-alpha-distro-mac-compatible.zip
i've been working a lot with uzi and peek~ and found it as reliable as any other max objects.
for large buffers it might not be the best choice, cause of massive max event traffic, which is eventually getting really slow. but this is best handled in an external anyway.
using signal objects is a different approach (with pros and cons) and might be just fine for what you want to do. but then, everything has to happen in realtime, which is mostly even slower than uzi+peek.
below is a recreation of nao tokui's [slice~] object using only max objects (which is much slower than using the original...).
volker.
@volker
thanks for the patch. On a quick tryout, it seems to be working better than the slice object. There are also more parameters exposed, so I assume that I should beb able to tweak the results more.
thanks again ..