this is a sequenced beat slicer with a [bonk~] based slice-analysis engine.
i partwise borrowed this idea from saturno in a technical issues thread (http://puredata.hurleur.com/sujet-3178-graphical-data-structure-plotting-signal).
@ saturno: i hope, you don't get this wrong and you'll like this patch though.... i didn't want to leech your idea, but this sounded so interesting to me, that i couldn't wait for your patch..... and i'm still looking forward to your patch.
i also stole the [bonk~] analysis engine from a patch of tim vets.
thank you both! hope you don't mind!

i thought i'd share it here, maybe someone likes it! enjoy!

edit: the second version - see attachment 2!

http://www.pdpatchrepo.info/hurleur/ChopSuey.pd

pretty cool man!

thank you!

Hey man, this is nice! I actually started work on a [bonk~] based slicer a few months ago and got a little side-tracked with school. Hopefully I'll be able to get back to it soon and post it up.

Anyway, I mention this because I thought you might be interested in a little trick I used to get accurate beat detections. When the analysis is run, it uses the number of samples taken between the start of the analysis and the first beat detected and subtracts it from the sample numbers detected from every beat. It essentially auto-offsets the beat markers by the amount of [bonk~]'s delay. Doing this, I've found that beat detections are usually never off by more than just a few samples!

Actually, now that I think about, it might even be better to just have a preloaded array with a one-shot sample in it that you know is cut well, then use the method I posted above on that to calibrate the offset time. Then, you wouldn't need to worry as much about loading in loops that aren't cut well, as those might give bad offsets.

that idea is cool, i will probably implement that. at the moment i only subtract a constant value to set the slice markers a bit earlier. for most of my (mostly well cut) loops, this is quite ok, since i use a 5 ms attck time for each slice.
i'm looking forward to see your patch!

btw, when i consider that, i'd say, bonk~ should normally have a more or less constant delay, so it should be the right way to substract a constant value instead of calibrating the measurement every time, isn't it?

It's inversely proportional to the sameplerate.

According to its documentation it uses a 256-point window for analysis. So the phase in seconds is 256 divided by samplerate.

something about 6 ms at 44.1 khz... i substracted 4 in my patch, so for those who want to change it - it's on you!
by the way, at the moment i'm building the same patch without bonk~ for analysis. works quite good and the trick is pretty simple.
i'll upload it, when i have finished it....

Great patch! Perfect for "glitchy" style electronica. Marker editor and data structure visualization are killers here!
Do you plan to add more effects (something like a clipper, stretcher, distorsion etc) in addition to reverse?

Regards,

AlbertoZ

thank you! at the moment i implemented a stutter with 3 variable speeds and a pitch adjustment per step and i kicked out bonk~, because i found a good and more cpu wise way to slice the loops. i also thought about a stretcher...a bit crusher could be nice too...
i'm afraid, this will become a huge gui....

Like this - good work

thanks!
here's a second and more enhanced version, i added a kind of stutter and a grain-stretcher and this one works with a pretty simple but useful peak detection instead of bonk.
i attached the new version to my post at the thread start. download "chop_suey - 2.pd".
let me know, what you think about it!

edit:
sorry, i forgot to add some comments, check out the comments in my first patch!

edit 2: the "rst" button in the "grain" sections of the stepsequencer sets the granular stretch to off, so pitch changes do affect the play speed of the slices again.

this all is quite extendable.........
i kicked out some bugs and the marker editor. instead you can now shift the slices with a position slider, delete them with a shortcut or insert new slices with a slider and a shortcut. you can also now shift through the slices via the file keys. and i implemented a feature to dump all slices as single files to disk. it's getting almost "recycle"-like....
maybe i'll upload it....

http://www.pdpatchrepo.info/hurleur/chop_suey_3.jpg

Maybe?

if you'd give me you email adress i would send it to you, but i not sure if i want to upload it here. if i look at the downloads counter, then i'm sometimes a bit disappointed, that so many people download the patches i upload but only a few give me some feedback about it - i don't know if it demanded too much,but even if i'm a pd noob it's still a lot of work, building patches like these, and it took me many hours to build this one. so i think that people who download and use it, could at least leave a comment or a suggestion what could be done better, or what....
if i download patches from others, i also leave a comment.

edit: don't get me wrong, i don't want to sound sour... it's just what i said above, and of course i will upload patches here in future, but maybe not all and maybe not those, which took me much work. but i would be the last, who would refuse to share a patch with someone who supported me from the beginning, and of course you pertain to those people.

I love your patches toxonic, thank you very much for sharing your hard work!

hi toxonic

I wanted to tjek out your transient detection can you elaborate a bit on how it works.

mvh Steffen

@ excalibur: thank you very much! it's not that i only want positive feedback like yours (although i'm very happy about that, haha), but a little feedback at all is not demanded to much, is it? .... anyway, thank's!

@ pulsed:
oh, my "transient detection" is that f'ck'n simple that i feel ashamed to publish it here, but for me it works pretty well:
every time a loop is loaded a tabplay~ will play the new loop. tabplay~ goes into a [env~] to put out the envelope followed values in db, this then goes into a [moses] where you can now set the threshhold, e.g. 75, so the smaller values go to the left outlet of [moses] wich then trigger a [0( message, the greater ones go to right outlet wich then trigger a [1(.
both message boxes now go into a [change] to avoid repetitive output of numbers. and then it goes into a [sel 1].... this now always sends out a bang, when the threshhold gets exceeded. now i only measure the time between the bangs with a timer, subtract it by 14 (this i figured out by try and error) to offset the markers and make a list of it. so i got a pretty simple peak detection and for me it works good enough. i guess for other loops than drumloops, bonk~ would be the better choice but also more expensive.

so here again:

[tabplay~]
|
[env~]
|
[moses] <--- here set threshold for peaks
| |
[0( [1(
| /
[change]
|
[sel 1]
|
[timer] <- feeded into its right inlet, the left must be
| banged immediately before tabplay~
now make a list with

or whatever.

Here's mine using boink~. The key is to put the beat detection in its own subpatch and then use a [switch~] object to turn DSP in it off and on as needed.

http://www.pdpatchrepo.info/hurleur/findhits.zip

ah, good idea with the phasor-reset and the snapshot~ in the [pd detect] subpatch, when switched on. and sample accurate. i did not try it out, but looks like it was even more expensive though?
anyway, this is really neat!