In the coming weeks and months i will release lots of stuff i have been working on as a library of pd modules called the 'DIY-LIBRARY'

part one is "DIY-perk"

containing:
11 tweakable percussion sounds all programmed in fairly simple (mostly vanilla) pd.

BASSDRUM

HIHAT

SNARE

CLAP

FM HIHAT (thanks to andy obiwan)

COWBELL (maybe not actually a cowbell)

LOW TOM (thanks to stefan ichabod)

HIGH TOM (thanks to stefan ichabod)

AK47 GUNSHOT (thanks to andy obiwan)

BELL

CRASH CYMBAL (thanks to stefan ichabod)

requires a basic pd-extended installation (google 'hans pd installers' if you don't have this)

sssad is used for the state saving, and is included in the .zip

i have included a very basic generative sequence to demonstrate the sounds, but please sequence and mix using your favourite pd techniques.

NEXT:

about 50 modules for building synths and effects units. stay tuned.

http://www.pdpatchrepo.info/hurleur/DIY-perk(ok).zip

oh, a couple of notes and requests:

* some of the sounds here (especially the hihat/cymbals) use quite high frequency oscillators. i'm using a standard 44100hz 16bit soundcard, but i have a feeling that the aliasing of the oscillators is colouring the sounds quite a lot. i'm worried that they won't sound at all the same on soundcards with higher or lower samplerates. if anyone could confirm this, i'd be really pleased.

* my synths and effects currently use the same general architecture as these drum patches. ie, rows of GOP sliders. these patches also use the same sssad state saving system. ideally i want to make it all as simple as possible, so i can share with non-pd using friends, in a way that they can just connect boxes together to build their own DIY pd music without having to build everything from scratch. i would like to hear any comments on the pros and cons of this architecture before i tidy all my other modules up.

cheers mates!

Hey matt,

apparently your zipfile contains a file with an '*' (perk-*PERCUSSION.pd) character which windows does not really like.

edit (a couple of minutes later):

i'm trying out some of the individual modules, it seems that each module looks like this:

[inlet]
|
[pd theActualModule]
|
[outlet~]

So I replaced inlet by a bang and the outlet by a [dac~] but most of them don't react to the sliders and hardly generate any sound here. They load fine and pd does not report any errors on missing objects or so.

Strange?

Domien

ok, i replaced the original .zip with a version that fixes those problems.

All great sounds! Nice 808/909 style percussion.

Why use [initbang] instead of [loadbang]? initbang isn't vanilla so when I load it in some versions of Pd you have to open each patch and click the startup messages. Apart from that - it's wonderful.. cheers!

Everything works perfectly now and indeed sounds very 808/909 style (which is lovely imho). Fantastic work!!!

Just one minor remark, wouldn't you consider setting all sliders to "jump" mode? Like that you can very quickly try different parameter settings. But that's just the way i like it, and others might not of course.

Can't wait to play with those other modules you have in store!

D.

PS : i'm also using a couple of patches to do tempo distribution to all my patches and some others to allow a four-bus logical audio path (which can be assigned to any of 4 physical stereo outputs on a soundcard). if you want i could send you those, maybe they also might be useful building blocks.

This is a lot of fun to mess around with!

thanks for the quick replies. cheers.

>>Why use [initbang] instead of [loadbang]?

well, i changed it now because of its obviously troublesome nature, but the reason i used it was to simplify the GOP templates i was using. any loadbangs in the audio processing guts need to be triggered before the loadbang in the parent that sends the default slider values. so i thought that by changing any loadbangs to initbang would be the simplest way. i also thought that maybe initbang had become sort of semi-vanilla (maybe something like a caramel vanilla malt), but i was wrong.

how it works now is that any loadbangs in the audio processing subpatch are changed to [r $0-loadbang], and then the parent sends before triggering the slider values.

>Just one minor remark, wouldn't you consider setting all sliders to "jump" mode? Like that you can very quickly try different parameter settings. But that's just the way i like it, and others might not of course.<

hmm, personally i prefer the steady mode. but i have attached a little patch that will let you set all sliders to jump mode. just cut and paste the contents of this patch into each module, set to 'jump' and then save the modules.

http://www.pdpatchrepo.info/hurleur/steady-jump.pd

ooh, time to make a drum machine out of these

your sounds confound my ears, hardoff. Jeez, with the automation possibilities of these sounds I'll never need another drum machine. That's what I said about pd sequencers when I downloaded your juno sequencer, and I haven't readjusted that opinion yet.

I'm curious about the color rgb sub patch you have on each drum. Are you integrating computer aided synesthesia into your machines by any chance? I'm trying that right now.

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

This is really great stuff!

I have just recently been trying to build tight snare and bass kicks from the ground up.

these rock my socks a bit.

a lot to learn from here. many thanks to all who contributed and built these

# Hi,
# I'm getting this errors, while loading:

libdir_loader: added sssad to the canvas-local path
sssad $1/controls
... couldn't create

# and this one: "error: inlet: expected '' but got 'list'" while playing. And the sssad mechanism does not work. But the audio process works wonderful! I like to be able to use the state saving mechanism with this great drum machine. Can someone help? My Pd version is: 0.40.3-extended-20080505

yes, there is a problem with sssad and the libdir loader hans uses to make pd-extended.

as far as i can gather, the only option is to remove sssad from your version of pd-extended. i'm pretty sure i included the sssad files in the folder with these patches, so if you just remove sssad from the pd-extended path, it should work.

# Thanks! Problem solved as you said!
# The DIY-LIBRARY idea is very important. It will make beginners integration to PD easy. And shows its potential. Thanks for your initiative!

more coming very soon. just got to write up a document on [sssad] usage, and then it will be ready to go.

new version includes: these 12 percussion modules, 15 synth waveform generators, 32 effects, 5 sample-players, lfos, adsr envelopes, and state saving.

i'm very excited to have this near completion.

Hi Hardoff,

maybe one of the important things to mention about the DIY-LIBRARY
is the easy integration into existing projects. It's just matter of

1. pasting the necessary abstractions +perk-*.pd + "_sssad" folder + "settings" folder into
the existing PD project folder
2. building up a sequencer (i.e. replacing your example "generative-sequence" provided in
perk-aPERCUSSION.pd with what is desired)
3. catching all the $0-drums and mixing with the existing inputs to the dac

Simple like that. Great, man...

I tried the whole perk-aPERCUSSION.pd patch into an exisitng PD patch using the included
"generative-sequence" and I'm happy to say that it works lovely and smoothly!

BTW, i don't know if it's my sssad system not working correctly but when I try to open another preset
I got a wrong concatenation of the path: if I try to open hardoff-drums.txt I got in the PD console:

...
tried C:\\alberto\\backup\\PureData_Archive\\patches\\XYZ_evol settings hardoff-drums.txt and failed
...

while it should probably be:

C:\\alberto\\backup\\PureData_Archive\\patches\\XYZ_evol\\settings\\hardoff-drums.txt

Win Xp, Pd version 0.39.3-extended, no sssad on my PD path.

Thanks for sharing, can't wait the next coming DIY set!!

Cheers,

AlbertoZ