here is the updated version of my DIY library. it is a collection of various useful audio modules for music production.

unfortunately my pd computer packed it in last week, so it is in a bit of a 90% completed state, but there should be enough stuff to play with until i get a chance to get in and get it all 100% done.

open 000-introduction.pd to get started.

http://www.pdpatchrepo.info/hurleur/DIY2.zip

Hi Hardoff,

I'm surprised to find that I have not earlier recorded my amazement and appreciation for this incredible piece of work.

CeC 2009 is due up next weekend, and I was just looking it over again for my performance,... but I just can't play guitar with the latency of computer-processing~:o/ http://www.theaea.org/cec_cac/cec09/index.htm

Will however, be using Marco's very interesting C::NTR::L (http://puredata.hurleur.com/sujet-2382-ntr-live-improv-physical-computing), to sort of demonstrate live video-processing,...... with an environmental theme of course.

Wish you were here with us again to turn it all on properly.

Keep well buddy ~ Shankar

Hi Hardoff,

About your 303 seq, is it possible to set the sequencer without using the Gui ? (with a message or inlet).?

Thanks for this amazing work.

hi shankar, hope it all goes well for you on the weekend. onwards and upwards.

xray:

>>About your 303 seq, is it possible to set the sequencer without using the Gui ?<<

yeah, you could make it do that. the sequencer has state saving (those 808_state patches), so you'd just have to look at what messages are being sent from the state saver to the sequencer and add them in yourself.

this is not an 'out of the box' function. it's something you'd need to add by yourself, but it shouldn't be too hard.

Thanks Hardoff...

Will try that ... (i want to integrate a 303 in my reactable under dev)

cool. if you get stuck or have questions, feel free to email me: hard.off@gmail.com

hardoff, this fucking great! I've been playing around and studying these, and I'm learning a ton.

I was looking at your bit crusher to see how you handled sampling rate ([samphold~], duh...for some reason I thought it would require some weird [block~] thing), and I noticed something about the bit depth that didn't look right. You have it multiplying up and dividing back down, but it's not actually quantizing to the lowered bit depths. An [expr~ int(v$1)] does the trick. I don't know why the sound is still being affected, though. I'm guessing floating-point error, but who knows.

Anyway, thanks so much for this library. It's one of the most helpful--if not the most helpful--things I've come across for learning DSP in Pd.

http://www.pdpatchrepo.info/hurleur/mono-bitcrusher.mmb.pd

cheers, that bitcrusher always bothered me too.

unbelievable Greatest thing I've ever seen

This seems interesting, but I can't get it going. When I open 000-introduction.pd, I get this message:

getdir
... couldn't create

Then when I click to start, I get this:

error: inlet: expected '' but got 'bang'

I'm assuming that's because [getdir] was never created. Where can I find [getdir]? Is it an external? Do I need to download it from somewhere? I'm running Pd 0.39.3-extended.

Thanks!

[getdir] is part of the ggee library. Try [import ggee] or adding ggee to Startup... and then typing a [getdir] to see if it works.

I've come back to this library in the past few days, because the effects are really great as seasoning for that point when you're almost done with a composition but then decide that it needs something more. The "wetfilter" is a particular favorite.

But I've been wondering, how exactly does "specdelay" work? I think it sounds amazing, but I don't know enough about Pd's FFT objects to know what's going on.

i'm actually not entirely sure on that one myself, it was originally based on a patch made by Frank Barknecht i think.

bascially, as far as i can figure, it's like this:

FFT gives the amplitude (and phase, i think) of a gradient of frequency bands, and then reconstructs the signal from that information. So, a signal goes in as a normal block, and that is transformed into the FFT realm, which means that your block now has the amplitude information for each frequency in the gradient.

then, we can do things to the block of audio to modify it. the simplest example is making a graphic EQ. if the FFT block is multiplied by another table of equal length to the block size, then the values of each point in that table will scale the output of each frequency in the FFT block.

in a similar way, if the FFT data is sent into a delayline, the amount of delay can be set seperately for each frequency in the block. the original patch i based my spectral delay on had the delay times being written from a table. however, i found that an acceptable substitute for the table was to use a sine function to define the delay at for each point in the FFT.

there is also feedback and stuff, and that works just like it does on normal signals, except it acts on individual frequencies.

Hey I got a question. in the compression patches I can kind of get my head around the amp factor section. But I don't get any of the att/rel section. Can anyone explain what that sgn~ (signum) is/does ? Secondly I can see the table is effected by the release but not really on the attack. I can hear the attack. The block size is 2. I'm guessing if the default block size is 64 samples then 2 means 128?? Or is it actually 2 ? This outputs a frequency between 0.019 and 57 into a VCF along withe the original amp factor. Any advice ?

that's a patch i nabbed from the net-pd library i think. actually it seems to work ok, but from what i have read, a block size of 2 might not actually work. yes block 2 does actually mean it should have a size of 2. some people said on the pd list that pd is hardcoded to limit blocksize above 32.

i don't really know what signum~ does, and i have never used it (except in cases like this where i have borrowed whole patches)

you could email roman who made that patch and ask him i guess. pretty sure his mail address is on the netpd site.

Ahh ok cheers.

[sgn~] is just a sign function. I've never been able to figure out Roman's compressor, but if you want to learn about simple limiters and compressors in Pd, try the ones from Johannes' pd-tutorial.com. I personally prefer using his limiter patch to make a classic compressor with makeup gain.

@hardoff said:

some people said on the pd list that pd is hardcoded to limit blocksize above 32.

I don't think that could be true, because if you check out help patch G04.control.blocksize.pd, where [pd delay-writer] has [block~ 1], you can go above 1378.12 Hz in the delay loop (whereas you can't with block size 32). But there do seem to be tuning problems when you get up in that range.

Also, here's a simple compressor adapted (ever so slightly) from Johannes' limiter.

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

Woa cheers ichabod. That website looks really useful.

I think ichabod's right. I've made comb filters with [block~ 1], and you can clearly hear the difference between a 1, 2, and 3 sample delay.