any slicers or offset samplers in PD?

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/

yeah i seen that. the only thing i dont lilke is that it cuts them into random order.
but maybe i can edit the patch to keep it from doing that?

i have seen hardware dj mixers that output a fairly accurate LED bleep in time with tempo - and i very much doubt they are doing any sort of spectral processing. would be cool to find out how they do it.

@hardoff said:

i have seen hardware dj mixers that output a fairly accurate LED bleep in time with tempo - and i very much doubt they are doing any sort of spectral processing. would be cool to find out how they do it.

huh? wrong topic?
not trying to be rude but i'm not sure why you said that

The difficult part of a good beat slicer is a circuit that can accurately find where the beats are in the audio. It's spot on topic. But alas the DJ mixers are finding the peak signals, which isn't the same as accurately finding the starts. The more I think about it a two pass solution using [bonk~] looks the best.

Actually they are doing spectral processing of a kind... simple narrow band analog filters

@Laserbeak said:

@hardoff said:

i have seen hardware dj mixers that output a fairly accurate LED bleep in time with tempo - and i very much doubt they are doing any sort of spectral processing. would be cool to find out how they do it.

huh? wrong topic?
not trying to be rude but i'm not sure why you said that

months later now i get why you said it. :P
ok anyone make progress with this? hehe? i'm back i had some family issues and had to take a break from a lot of things..

@obiwannabe said:

the DJ mixers are finding the peak signals, which isn't the same as accurately finding the starts. The more I think about it a two pass solution using [bonk~] looks the best.

what do you mean by two pass?

Two pass is where you scan through some data or code twice, first to build a list
of markers/tags, and then going through the data again applying some function which
uses the tags, like building an index. Because [bonk~] acts on a signal, not an array, one would need to store the sample in an array first then read it out with [tabplay~]
through [bonk~] to create a second table of markers. That's a roundabout kind of way to do it, far less elegant than just operating on the data in the array, but as we have decided we don't really have any good feature analysis tools that operate on stored data in Pd. Does that make sense?

definately more than it did before obi. but what about aubio? what do you feel about that? and trying to figure out how it was used in freecycle? that sounds like a way to go as well. to be honest i dont really care what way we take as long as we take into consideration all available paths first. cause then we might know what's the best path.(?)