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!

[--------][--------][--------] <--- block 1st overlap
----][--------][--------] <---- block 2nd overlap

i think it's like that with an overlap of 2. all SIGNAL operations occur twice, with the block start time offset on the 2nd overlap.

for overlap of 4, you have 4 threads, with only 25% block start offset between each successive overlap.

this is just my guess how it works though. i didn't read anything, and just figured it out by trial and error.

great ideas there.

the attached patch follows most of what you suggested, with a little bit of pd knowledge.

the main thing i have exploited is the use of overlapping blocks. right click on a block~ object to get its help file and more info about that. basically, with a block overlap of 2 (default is 1), every process in the block is augmented by the same process triggered 50% of the way through the playback of the first block.

that takes care of a lot of stuff automatically - the crossfading between 2 tables, the phased-playback of the 2 tables, etc.

"2 tables?", you might ask, when you open the patch and see that there is only one table. Well, with the overlap, another table is automatically invisibly created to be read by the overlapped block.

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

hi all, doing a little 2d collision detection here very simple and i found frank' patch here: [html]http://www.mail-archive.com/pd-list@iem.at/msg06087/collision-detection.pd[/html]

if you run the patch asis, the collision detection occurs only when the middle of the smaller circle hits the outside of the bigger circle...

i can see the variable the changes this.

i.e. i want the collision detection to occur when the outside of the smaller circle hits the outside of the bigger circle.

if im not clear i can attempt a rephrase, but any help on this matter would be greatly appreciated...

im sure its a number box somewhere but i cant see where

thank you.

The reason why it's not working until you open [wrap~]'s help window is because audio needs to be turned on. The help patch does this automatically with:

[loadbang]
|
[; pd dsp 1(

So I'll try to explain how this patch works. It's based on using a master [phasor~] object for everything to sync to. I used beats per minute because Hz is the same thing as cycles per second. By dividing bpm by 60, you get beats (cycles) per second. It's just easier math (to me) than using ms, and it's more musically intuitive anyway.

The signal for the [phasor~] is multiplied by the beat division, scaling its range. So if you want the beat divided into four subdivisions (16th notes), it will be scaled up from 0-1 to 0-4. [wrap~] takes a signal and wraps it around so that it falls within a range of 0-1, so 2.3 will become .3, etc. It essentially just gives you the fractional part of a number. Sending the scaled up [phasor~] output to this results in a ramp that is synced to the subdivision. This is then subtracted by .5 to scale the range from -.5 to .5, just so there are some zero-crossings.

[zerox~] is used to detect the zero-crossings. It doesn't seem to have a helpfile, and I'm not sure what the difference between the to outputs are. I just know they very briefly spit out a 1 when crossing zero. [edge~] detects sudden jumps in a signal and outputs a bang, which is used to drive the counter.

It's just occured to me that [zerox~] detects zero-crossings going up and down, and I designed the patch with the idea that it should only detect signals crossing downward. So it's actually going twice as fast as it should! Dividing the bpm by 120 instead of 60 should remedy that.

Hope that helps.

Hey all-

Is there a way to append samples to the end of a wave file in PD? I'm working on some voice activity detection stuff, and I basically want to read in a multi-channel wave file, determine if every 80 samples is speech or non-speech, and add another channel that contains the information about speech / non-speech.

I would like to write all of the original channels, plus the new channel, to a new wave file. My concern is that the channels will be too large to simply load them all into arrays, and then write out all the arrays (maybe I'm wrong and maybe I should just do that). I would like to basically...

read in 80 samples
determine speech
write out 80 samples (on all 5 channels)
repeat until the end of the file

Is there any way to do this? Or should I just try to load them all into arrays and just write the file @ the end (the files are like 20 minutes each, 4 channels, 8kHz).

I've looked at soundfiler (will let you skip parts of the array, but not parts of the file) and writesf (seems to only write in real time; stopping must be followed by an open before more writing, which overwrites the file)...

Any help would be appreciated!

All the best,
-Zach

I'm fairly new to PD and am having trouble figuring out how to do something quite simple. I want to be able to get a bang whenever a certain sequence of two tones is heard by PD. I'm using fiddle~ to do the pitch detection and am able to detect single tones, but I want to be able to detect a sequence. For example, if I detect a pitch 61 followed by pitch 74, I want to output a bang. If I detect pitch 61 followed by any other value, I don't want any output.

In C, I would write something like:
if ((current_value == 74) && (last_value == 61)) do_something();

How do I do this in PD?

Hi pure people,
I am new to pure but an experienced software developer.
I use PD for an interactive audio installation and especially GEM for the actual video processing and movement detection. Allthough it works fine on my development plattform, an old ibook G4, a few differences of the behaviour betweeb Mac and Windows of some GEM objects make me worry.

My development machine (on the go... is an old ibook with tiger (and an ati 9200) and a new pc with xp sp2 and a geforce 7600. The target plattform will likely be a pc also with xp sp2.
The software I use is the pd-extended 0.38-4 release.

My development works as this: I use a movie that is prerecorded and shows movement of a single object (like an elevator moving up and down with stops in between).
My patch is partially build like the GEM documentation example Gem - 04.video - 0.3.movement_detection.pd. Additionally to this I have subpatches that do movement analysis patches for speed and accelleration of a single moving object.

On the mac (with an ATI 9200) the initial view of the prerecorded movie is quite dark and the basic movement detection is very sensible and works quite well (and also the analysis).
On windows (with a geforce 7600) it is different. The movie looks quite normal, with the normal brightness (the mac was very dark), and the movement detection is very insensitive and does not really work.

Things that I recognized and resulting questions:
1. Is there a difference in initial values the GEM objects have if there is no explicit initialisation?

2. The colormodel seems to be different. A color of 1 1 1 is black on the ibook (with the ATI card) and white at the PC (with the geforce)

3. What reason can it have, that the displayed video on the mac (with the given example) is initially way darker than expected.

4. On the mac, the prerecorded movie cycles infinitely with the auto option of pix_film whereas pure on windows stops after one cycle. Is there a reason for this behaviour?

5. Is there actually a difference between the way GEM objects are initialized between Windows and Mac and also between different opengl vendors (like the color model between ati and nvidia).

Hope someone can share some experiences with GEM and how to work around the difficulties of GEM on different plattforms.

Regards,
Michael.