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

@hamster said:

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

Maybe you could talk a little about your process for this? If you have some time. It is really, really lovely.

I'll describe how it works in detail a bit later, because there are 2 difficulties: 1) to explain it in English which is not my native language, unfortunately. 2) to remember what several parts of this patch do. I made most of this generator a year ago or so, and can't remember what some objects do in it, because I didn't use comments! Shame on me..

This is phenomenal! I love it; such great atmosphere! Thank you for posting and keep on making music!

Oh wow! Magical it is, listen i must!

Really awesome work!

Great work, hamster!

Like lead, I've been playing this patch for over an hour and continue to be impressed. Along the way, I printed everything out and have been analyzing your meditation generator.

I'm not done yet, but the following may help others get started with their own analysis:

Starting with main.pd and working your way down:
1. main.pd can be broken down into three major sections. The top section consists of everything between [metro 5000] and [snapshot~] / [route ...]. The middle section is the row of ten identical structures that each start with a [stream~ ...] and end with a pair of [throw~ ...] objects. Finally, there is everything below those ten structures.

2. The top section produces LFO modulated envelopes on the left and ten-note sets on the right. This data is passed down to the middle and bottom sections.

3. The middle section is a row of ten similar synthesizers. Each synth gets its initialization from the top section. The meat of the synthesis is in [stream~]. As far as I can tell, it is very carefully filtered noise. The output of [stream~] is sent to a tuned bandpass filter, and then panned slowly from left to right.

4. The bottom section has four significant subsections: The mixer/processor is at the top left and the pad generator is on the right. Below these two sections is a pair of custom reverb units. At the very bottom is the [master] output and recording section.

5. I don't fully understand what is going on in the mixer/processor, though it appears that the left and right channels each get bandpass filters (by stacking a pair of [hip] on top of a pair of [lop]) and are randomly assigned independent control envelopes.

6. The pad synth on the right sounds like white noise, but is built around a trio of [osc~] units. Ironically, the ten identical synths in the middle section are built around [noise~] but don't sound like noise!

7. The custom reverbs are defined in [freezeverb]. It seems to be built on a total of 28 300ms delays. I don't understand how it works, but the layout is very nice to look at!

8. Finally, the output and record sections at the bottom seem fairly obvious.

*fakerep*

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.