any slicers or offset samplers in PD?

Right, OK, but is that what you had in mind? I'm trying to figure out what you mean by slicer.

yeah something to take a file cut it into segments and allow me to control how the segments are played back
i'm sure you've heard of recycle right?

It sounds like you're trying to combine an analog sequencer with a chopchop style program as well as lots of timestretching and transposition subpatches - I think you might be better of just buying Recycle if that's what you want.

Edit: if you're not looking to spend any money, there's always Freecycle:

http://www.redsteamrecords.com/freecycle/index.php

yeah i seen freecycle i was thinking uf modding it when i finaly migrate to linux

a slicer in pure data, very good suggestion, we're going to work on it...

I am thinking about using one array for one slice and fft timestretching in each array, it might be a very heavy patch.

can i join you?
msn malik_martin at hotmail.com
aim laserbeak43
yahoo laserbeak43

I was thinking dismissively about this today, "Crazy kids and their beat slicers..."
Then I remembered it's actualy non-trivial, in fact it can be a pig of problem to do properly.

May a suggest that it be split up into sensible software components.

The first two parts are easy really, the table manager for storing samples in arrays, flatfiles or whatever, and the resequencer or slice dumper that can nicely envelope each chunk and play it or write them all as incrementally named files somewhere.

The third part is the bitch. We need a beat detector that can find startpoints. Easy with a nice clean recording, but with the Amen beat for jungle - that's the trick. Some kind of spectral differential is called for hooked to a look-ahead and look-back inteligent zero detector. (want to catch them on a positive going phase) Crack this and you've basically done the hard work.

The sub-unit should take an arbitary sized file and return a list of indexes that correspond to the start of an event according to three or four spectral thresholds, one for high, mid and low events (hihat, snare and kick)

As an aside, I used Recycle way back, I don't know if they improved the algorithm significantly since but honestly I found it a piece of crap, really sloppy at false positives caused by clicks or dicsontinuities, really naive algorithm which always went for the minima before a beat even if it was obviously way too early. I had a production job for a band which involved a lot of beat cutting and in the end I ditched recycle and went for cutting them by hand in cool edit, much faster. Steinbergs programmers aren't idiots, which leads to me to think there's a lot to doing this well.

It might be worthwhile to cop Freecycle's beat detection code as a Pd external.

i think there are plenty of methods of doing it.
lets say we had a tempo of 180 bpms
each bar would be 1.33 seconds.
lets say that we didnt really need to slice every transient(is that the name for it?)
but we wanted to simply take a preciesly cut amen and loop it and sync it but cutting it into 8 parts
then we sould have figure out an algorithm like.. 1.33/8(?)to get how many ms the 1/8 segments are(??) sorry nmy math might be wrong but you get the idea.

and if the tempo decreases or increases just scale the tempo change up or down where 1.33 was t he bar length at 180bpm...

I like Mr Browns idea, I didn't consider the work is probably wheel reinvention. What would the interface look like to such an external? I imagine it being rather like [sfread~], send it an [open beat.wav( message and then follow up with a threshold value(s) and n beats to find and have it return a list of n values which are floats in seconds into the file where a beat was found, that would be a valuable atom for many apps.

BTW I was looking at your site, wonderful stuff, the SpinOSC thing made me remember this which I think you will find fascinating, an Italian composer gave me the link a while back and it's a gateway to a whole new take on geometric music, really fresh ideas..

http://www.zogotounga.net/GM/eGM0.html

Laserbeak, the method you mention is cool, but it's "brittle", you need to know beforehand what the tempo is and if you get it wrong the system breaks. The beat also has to be perfectly trimmed at the start and endpoints, but don't hold back on starting on that account, you can always improve it later if a better detector turns up.

@obiwannabe said:

I like Mr Browns idea, I didn't consider the work is probably wheel reinvention. What would the interface look like to such an external? I imagine it being rather like [sfread~], send it an [open beat.wav( message and then follow up with a threshold value(s) and n beats to find and have it return a list of n values which are floats in seconds into the file where a beat was found, that would be a valuable atom for many apps.

BTW I was looking at your site, wonderful stuff, the SpinOSC thing made me remember this which I think you will find fascinating, an Italian composer gave me the link a while back and it's a gateway to a whole new take on geometric music, really fresh ideas..

http://www.zogotounga.net/GM/eGM0.html

Laserbeak, the method you mention is cool, but it's "brittle", you need to know beforehand what the tempo is and if you get it wrong the system breaks. The beat also has to be perfectly trimmed at the start and endpoints, but don't hold back on starting on that account, you can always improve it later if a better detector turns up.

i'm interested in both ways honestly. just seemed like that would be less of a burden. but if you guys were willing i would definatly like to learn with you, how do do obiwaqnnabe's idea. as far as frecycle.. i'm a bit of a coding newb, so it'll be hard to even build the libraries to make them fit inside of any IDE i choose. but if anyone would like to join me and maybe help me build, i'm sure i could pull my own weight.

i've had the freecycle library for over six months now and havent touched it since i'm on windows.
if i can manage to make PD my main sequencer i'd have no problem migrating to linux fully.

http://cvs.savannah.gnu.org/viewcvs/*checkout*/freecycle/freecycle/src/soundmanager.cpp?content-type=text%2Fplain

I know it's a bit intimidating. Doesn't mean we have to use that code, just a start to get ideas. In fact it could be done as a pd abstraction using [rfft~] based on the methods. But before anything else important to check *someone has't already made one*, so I joined pd-dev .

PD Dev? where? what?

thgat is a lot of code!!!

This is interesting - pd-aubio looks like the starting point for a slicer.
Frank Barknecht wrote on pd-list

<quote>
I just saw an annoucement on LAD for this:
http://aubio.piem.org/

What is aubio ?

aubio is a library for audio labelling. Its features include
segmenting a sound file before each of its attacks, performing pitch
detection, tapping the beat and producing midi streams from live
audio. The name aubio comes from 'audio' with a typo: several
transcription errors are likely to be found in the results too.

The aim of this project is to provide these automatic labelling
features to other audio softwares. Functions can be used offline in
sound editors and software samplers, or online in audio effects and
virtual instruments.

Interesting news bit: It includes a Pd external!
</quote>

so theyve released it? i've emailed him about them but i never got a reply. there are two other aubio externals i think. but i couldnt get them to work...

dependancies for insalling aubio:

• automake 1.8
• libsndfile1
• fftw3
• libsamplerate
• libjack (optional)
• libasound2 (optional)
• swig (>= 1.3, optional, for the python interface)
• python, python-gnuplot, python-numarray (optional)

i gave up when i got to fftw3, which also has it's own dependencies to load.

heh yeah you'd have to take a good day or two to just set it up. so next time if you decide on trying, at least you know what to consider.

Sure. That's a harsh set of deps. Well, the fallback is to use [bonk~]
Problems with bonk are it works on a realtime signal, and it outputs a control rate signal. Which means you'd need to read in the file to a table, run bonk on it to get a load of markers, store them, and use them as indexes back into the table. The timing could be bad but unless one tries it there's no way to tell. The cool thing about bonk is it can use "templates" so you could get some pretty clever spectral recognition of various instruments. Also the detection skew is likely to be a constant so you could just offset the markers back a bit to get it working quite well I think. Have a think about it.

2 laserbeak: maybe this link will be useful for you... http://ftp.iem.at/pd/Patches/slicer/