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

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!

@toxonic I have been playing with Chop Suey 2 for a few hours this afternoon, and it is freaking awesome. Totally the best patch I have seen for PD yet. I would love to play with version 3. Any way you would share it?

Toxonic,

Awesome patch. Turned out that I've been working on the same thing for the past few days. I ended up with a [bonk~]'s raw out going to a [tabwrite~], then the timing read thusly:

[tabplay~]
|
[snapshot~] [metro 5]
|
[change]
|
[t b]
|
[timer]

The timer at the bottom gets the first bang from the same trigger as the [tabplay~].
Yours seems a bit more elegant, since you're not running the expense of [bonk~] and because you don't have to worry about the 5ms quantize that I'm getting from the [snapshot~] (which can eat up my 5ms slice overlap later on).

Thanks a lot for the patch. It has really helped me with cleaning up my redundant code.

Since the detection is a one time deal it's just a matter of putting it in its own subpatch and using switch~ to turn it off after mapping the hits.

An even more sophisticated way of doing it would be to then to save the hits map to the disc using the sample's MD5 hash as a reference. That way if that file exists just load it instead of detecting the hits, if not detect the hits and save it.

By using the MD5 rather than the filename you guarantee that any changes done to the original file force re-detection by the patch. Another side effect is that you might have the same file copied with different names and they will still have the same MD5.

Don't think there is an md5 object in pd. I'll whip one up later.

@ wakest: thank you very much! i think i will upload it, but there are still some things i'm working on... maybe at the weekend.

@ evilsheep: well, i guess it's a good starting point to use env~ and moses to set threshold. i recently added a kind of "auto sensibility" feature, to find the right analysis settings with every loop. i compared my slice detection method with a bonk detection and found that the results of my method seem to be more useful (at least, as long as you don't feed bonk with extra settings). for bonk~ you can set an upper and a lower threshhold, but you can easily add this feature by using a second moses. but i didn't find this useful in most cases.

ok, decided to upload the newest version chop_suey 3.2. this is probably the most "polished" version. changes since version 2:

• enhanced slice detection, more cpu wise and with automatic analysis settings when loading a new loop.

• markers can now be edited via sliders: visual delete, move and insert sliders.

• shortcuts: playback single slices through shifting through the loop with "shift + arrow keys". delete selceted marker with "shift + d", insert marker at insert position with "shift + i", play selected slice with "shift + p"

• dump slices as wav files: with the "dump" button you can save all slices as single wav files to disk (only the pure slices, changes in the sequencer or any other settings will not affect the files)

• smooth slices / amp envelope: set attack and decay up to 50 % of the slice length.

please leave a comment if you have any suggestions.
have fun!

http://www.pdpatchrepo.info/hurleur/ChopSuey_-_3.2.pd

That's really a great fun to play with it, everything is clean and neat.
Thanks again for sharing.

Few (two) general, high-level, usability comments:
After some playing, what I miss is a "randomization on the slice number":
after you get the whole number of slices from the analysis step, a button or similar
that sets randomly the slice number below the trigger toggles.
Another possible idea could be a save/restore function of the sensible interface
parameters (trigger, slice, reverse, retrig, speed, etc.) in order to recall previous
interface editings (independently of the loaded waveform..).

My two euro cents...

AlbertoZ

I love it!

It keeps getting better and better.

Thanks a lot toxonic.

@toxonic said:

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://puredata.hurleur.com/attachment.php?item=1408&download=1

yeah please upload it

look at the attached patch, 3 posts ago!

yeah i didnt see it at first:)

wow, that patch is PRO!!
i had already downloaded the first version, but couldn't fgure out at first.
i still need more time to play and check out the full potential, but so far i can say:
that's definetly inspiring stuff, thanks for sharing!!

Hey I loved the chop suey patch! great!

I have a very similar project that started based in a patch that i found in this forum[1]

checkout the nvl project: http://navalha.devolts.org/en

and let's merge

[1] http://puredata.hurleur.com/sujet-1953-sample-slicer-user-selectable-slices

I'm quite at awe - the patch is VERY good, I tried a few non-rhythmic samples with it and the possibilities are amazing. It seems to be very stable, I hit rapidly here and there and the patch just rocks on.
Congrats! Also, it is very nice of you that you don't shift the objects around in a way that one can't understand how the patch works. Inspiring to do good work..

thank you all very much!
@ glerm: i had a short look to your patch, although i didn't dig deep into it, it looks quite amazing. when i have a little more time i'll work on it. feel free to tinker around with both patches too.
@ ultrasonic: to be sincere, i was also surprised about that i found no trouble with working out that patch. seems that i had a lucid moment there.
and yes, i have a little "neurotic" building style, and i also like it, when patches are clean and tidy and don't look like a spider on lsd.

Awesome patch toxonic! Been playing around with it all morning.

Thanks,
J