Just unpack an archive, open main.pd and enjoy. Warning: may start with quite loud short sound.

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

Very nice!

Thank you all for your replies, I didn't expect such feedback. Especially thanks jamesmcn - everything was described well, I just have something to add:

1 and 2. The top section performs two functions - it's smth. like "probability generator" (leftmost part), which, in accordance with LFO, defines how often droplet sound is being generated at the moment, and (rightmost one) an array containing tones, at which [vcf~]s of certain droplets resonate (0,2,3,5,7,8,10 in it mean C-minor scale). And every 5 seconds [route] picks these tones (notes) up from the array randomly and sends them to [vcf~] objects after [stream~] abstractions. These tones are transformed into frequencies in Hz to control bandpass filters.

3. Yes, the [stream~] is the meat of the synthesis, but it is not "very carefully" filtered noise, although should be. I just tried to make it sound like water droplets, and made some variations in cutoff frequency (first creation argument) and stream density (2nd creation argument) to make droplets sound more diverse. The stream~.pd itself is actually a very simple noise generator, and this is the oldest part of the patch itself. I wanted to make something like a rain noise, made this abstraction, and put it off until it came into play.

4 and 5. You know, if you delete the mixer/processor section (except reverb), you may not notice much difference: it just makes left and right channel slightly different from time to time - for merciless freezeverb to mix up left and right channels in one stream anyway. Buy the way - [freezeverb] is just an enhanced version of that you can see in help -> browser -> G08.reverb.pd. The only serious difference is that it uses delay_time_counter.pd, which calculates the times for delay lines in accordance with this formula: t = t1/2^(n/numlines)-t1/2, where t1 = the largest early reflection delay time value, numlines = total delay lines number (28 here), and n = current delay number (starting from 0). I found this algorithm here: http://musicdsp.org/archive.php?classid=4#44 but changed it a bit (actually, added "-t1/2" to make echoes appear earlier. I still don't understand completely how [freezeverb~] works. To be more precise, I don't understand what actually does [early_reflection_delay_line] do - but Miller Puckette in his example applied similar [reverb-echo-del] abstraction, and it works well! It makes a "power-preserving" mix, very useful thing in recirculating reverbs.

6. Two sine wave oscillators take their frequencies from two first randomly picked up notes from an array (see item 1 and 2). There are also two frequency modulators, 1846 Hz and 4 Hz sine waves, to saturate their spectrum. So it sounds a bit like noise, mainly because there are already too much sine waves from the [stream~] abstraction, and I thought it worth adding something at higher frequencies. And reverb smoothes these oversaturated sine waves, making them sound noisy.

7. How reverb similar to [freezeverb] works is described in help browser, I just can't understand why power preserving mix works. Also I tried to make one stereo reverb based on Miller Puckette's model, but a couple of experimental ones failed. This one is my best reverb ever.

8. Yes, and [master] abstraction is just a place where volume control, or spectrum analysis, are handy to perform from. Something to put all the wires at, and to listen to its output.

Thank you for nice patch, it's inspiring.

It's also possible to change array containing tones for [vcf~] resonanses. For instance, 0,2,3,5,7,8,10 mean: C,D,D#,F,G,G#,A#. If you change numbers to 0,2,4,5,7,9,11 - droplets will resonate at C-major scale, giving another mood.

Hey, thank you guys for the explanations, it will be fun analyzing the code while enjoying it at the same time!

wow...really awsome...thank you!

I'm so curious to know what this patch does, but when i try to open main.pd it crashes pd on my laptop, well cpu goes to 99% and nothing happens anymore (winxp). Anyone has this too?

@domien said:

I'm so curious to know what this patch does, but when i try to open main.pd it crashes pd on my laptop, well cpu goes to 99% and nothing happens anymore (winxp). Anyone has this too?

Would you tell what version of Pd you use? I'll try to open this patch on my netbook with WinXP also. Haven't tested it on XP yet. By the way, just noticed that when I open it in Pd-Extended 0.42-5 under Vista - nothing happens. I mean it just doesn't open.

The patch itself was made in Pd-Vanilla mainly in Ubuntu Studio 10.10 64 bit. I'll tell what version of Pd I used when I get home from work.

I really like how it sounds, thank you!

Managed to open very glitchily on vista, guessed it might be vcf~ and freezeverb that were hungry, so quickly made a bp~/rev2~ based version (attached). Uses around 6% less cpu but sounds nowhere near as good, maybe it'll help offer some perspective debugging for other platforms.

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

Оk, and here are my test results:

1. Ubuntu Studio 64 bit, Pd-Vanilla 0.42-6, 2GB RAM, Core2Duo 2,66 GHz - all works well, 17% CPU approx. (96000Hz sample rate, 10ms buffer size! I love Linux )

2. WinXP 32 bit, Pd-Extended 0.42-5, Asus EEE 1000HE, 1 Gb RAM, Intel Atom 1,66 GHz. Works glitchy (no matter what audio buffer size is). 30-50% CPU. After changing freezeverb.pd to a simpler version with less delay lines (attached to this post) - 20-40% CPU and normal sound (48000Hz sample rate, 100ms buffer size). Rare glitches, CPU% jumps up to 50% at these moments.

3. WinXP 32 bit, Pd-Extended 0.42-5, 1GB RAM, Core2Duo 1,88 GHz. Works well, no buffer underruns, 20-30% CPU. (48000Hz sample rate, 100ms buffer size).

4. Vista 32 bit, Pd-Extended 0.42-5, 2GB RAM, Core2Duo 2,33 GHz. Couldn't open.

So, if you have difficulties with CPU consumption, try to change freezeverb.pd to a simpler version attached to this post. It sounds very close to original one.

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

awesome!!!!

I've been running this patch on Pd-Extended 0.42.5 on a Core2 Duo MacBook Pro with no trouble at all.

It is interesting to see that the Eee can't handle a patch like this - I've been thinking of getting a netbook for this sort of thing.

@jamesmcn said:

I've been running this patch on Pd-Extended 0.42.5 on a Core2 Duo MacBook Pro with no trouble at all.

It is interesting to see that the Eee can't handle a patch like this - I've been thinking of getting a netbook for this sort of thing.

I'm going to install Ubuntu NBR on Eee to work with Pd - maybe it can handle this patch under Ubuntu. I'll post here if it can. It seems like Pd under 32bit Windows can use only 50% CPU power, maybe Linux kernel works better. I have to use WinXP just to communicate with sampler (Korg Microsampler), because its utility works only under Windows or MacOS (it requires special driver which Wine in Linux does not allow to install, and I'm not such a guru to write my own driver, unfortunately ).

Otherwise, making patches on slow computers encourages to optimize them! Being initially made on Eee it probably could work much faster. Also, small screen stimulates using subpatches, so it makes patch itself look more intelligible: compare this messy generator with that abstraction (made on Eee) http://puredata.hurleur.com/sujet-4261-midi-learnable-mixer-channel

Thanks for sharing this great patch

If PureData only uses 50% CPU, could it be the case, that you have a DualCore CPU?

Linux may help, but my guess is that the Atom CPU is at fault here. All of the other machines discussed here have dual core CPUs with substantial caches.

I beg your pardon if this post is slightly offtopic and deals more with hardware than the patch itself, but it should take one more message for testing results to be complete:
@az said:

If PureData only uses 50% CPU, could it be the case, that you have a DualCore CPU?

Yes, all CPUs under consideration apparently had two cores, even Atom N280 on Eee - task manager shows two 1,66GHz cores. But I'm not sure its architecture has much in common with DualCore family. It looks slower than Core2Duo 1,66GHz. Well, anyway, it turns out that 50% CPU means 100% of one core under WinXP and Pd just can't distribute calculations between both cores to use more CPU in this case.

I just installed Ubuntu 10.10 NBR as 2nd OS on this Eee, and loaded this patch with Puredata Vanilla 0.42.6. It runs with no glitches at all with 44100Hz sample rate and 50ms audio buffer size! The same result with 48000Hz. But as I turned on 96000Hz, I even started hearing through glitches: "man, its just a netbook!" No matter what audio latency was set.

Task manager (named here "system monitor") showed 50-55% average usage of both cores (when 48kHz sample rate and 50 ms latency were set). Here it didn't mean that total usage was 100% (sometimes 80%-85% peaks appeared and again, no glitches). 50% CPU usage and no buffer underruns at all.

So, it's possible to use Eee with Atom N280 or later to make complicated patches, just under Linux. As for me, main problem is small screen, not Atom CPU, that's why I use it only for small abstractions and don't care what OS is installed. Also, if you'd use touchpad instead of mouse to work with Pd on Eee, I bet you'll say at least a couple of bad words in an hour of such torture.

Hey hamster, I'm sorry i diverted the topic from your - probably - very cool patch... Thanx for giving another freezeverb, that made it slightly better, but still my good old laptop refuses. It amazes me a little, since i'm running many of my own patches simultaneously before i can get it to its knees (usually 3 or 4 heavy patches, my masterpatch + 2 vst's). Oh well, that means that if I would upgrade to a new machine I'll be able to run much more pd goodness than i can now (a question which I had been asking myself for a while now).

If someone would be so kind to record a couple of minutes of this patch and post it somewhere (e.g. here : http://puredata.hurleur.com/sujet-5001-pure-data-users-soundcloud-group) that would be so fantastic!

d.

After talking with hamster via email, I've made a few updates to his patch and have given it the name he originally intended: "Cave of Creation."

I'm not sure why, but it seems to eat up a lot of CPU time until you turn it on with the on_off button at the bottom of the patch. ** Update ** Changing all references to "scale" to "$0-scale" seems to have fixed this, though there is only one instance of the scale table.

I've added boolean switches for each of the individual water drop synths as well as the left and right pad synths. I have also added a number of scales as well as a scale randomizer.

Per domien's request, I've uploaded a recording to SoundCloud:

http://www.pdpatchrepo.info/hurleur/Cave_of_Creation_1.1.zip

One of the best generative patches ever. Pure silk.
The reverb effect is great, mix of the various sources is awesome.
Thanks for sharing this gem.

Alberto