Kick sound on pure data

I saw some drum machine patches lately. I just wanted to share this method of making kick sounds. It’s basically the same idea of @manwithfeathers patch, but a little more elaborate. I think I got it from a MAX tutorial.

#N canvas 300 52 553 645 10;
#X obj 454 118 r \$0-trigger;
#X obj 454 269 log~ 2048;
#X obj 454 291 *~ 70;
#X obj 454 312 abs~;
#X obj 454 333 *~ 32;
#X obj 454 354 -~ 1200;
#X obj 454 400 clip~ 50 10000, f 18;
#X obj 454 422 osc~;
#X obj 454 467 *~;
#X obj 665 396 curve~;
#X obj 698 356 r \$0-o;
#X msg 454 226 0 \, 1 \$1;
#X obj 454 206 i;
#X obj 469 153 r \$0-decay;
#X obj 506 354 r \$0-resonance;
#X obj 506 376 expr $f1 * 130 + 20;
#N canvas 319 296 450 300 lin2log 0;
#X obj 84 -4 t 2 f;
#X obj 84 -83 inlet;
#X obj 84 74 outlet;
#X obj 84 36 pow, f 5;
#X obj 84 -34 * 14.29;
#X connect 0 0 3 0;
#X connect 0 1 3 1;
#X connect 1 0 4 0;
#X connect 3 0 2 0;
#X connect 4 0 0 0;
#X restore 529 549 pd lin2log;
#X obj 529 527 r \$0-filter;
#X obj 454 571 onepole~;
#X obj 469 175 * 8000;
#X msg 698 376 -0.1;
#X obj 665 198 r \$0-trigger;
#X msg 684 269 set \$1;
#X msg 665 300 318.182;
#X obj 684 226 r \$0-release;
#X msg 665 334 0.8 \, 0 \$1;
#X obj 684 248 expr $f1 * 2950 + 50;
#X obj 486 465 r \$0-gain;
#X obj 454 509 *~;
#X obj 454 531 clip~ -1 1;
#X obj 486 487 expr $f1 * 19 + 1;
#X obj 454 247 vline~;
#X obj 454 593 dac~;
#X obj 288 187 bng 25 250 50 0 empty empty empty 17 7 0 10 -262144
-1 -1;
#X obj 288 217 s \$0-trigger;
#X obj 288 270 s \$0-resonance;
#X obj 288 244 moonlib/mknob 25 100 0 1 0 1 empty empty empty 1 32
0 8 -191407 -66577 -4032 2900 1;
#X obj 288 294 moonlib/mknob 25 100 0 1 0 1 empty empty empty 1 32
0 8 -191407 -66577 -4032 9900 1;
#X obj 288 344 moonlib/mknob 25 100 0 1 0 1 empty empty empty 1 32
0 8 -191407 -66577 -4032 5000 1;
#X obj 288 394 moonlib/mknob 25 100 0 1 0 1 empty empty empty 1 32
0 8 -191407 -66577 -4032 900 1;
#X obj 288 444 moonlib/mknob 25 100 0 1 0 1 empty empty empty 1 32
0 8 -191407 -66577 -4032 0 1;
#X obj 288 320 s \$0-filter;
#X obj 288 370 s \$0-decay;
#X obj 288 420 s \$0-release;
#X obj 288 470 s \$0-gain;
#X connect 0 0 12 0;
#X connect 1 0 2 0;
#X connect 2 0 3 0;
#X connect 3 0 4 0;
#X connect 4 0 5 0;
#X connect 5 0 6 0;
#X connect 6 0 7 0;
#X connect 7 0 8 0;
#X connect 8 0 28 0;
#X connect 9 0 8 1;
#X connect 10 0 20 0;
#X connect 11 0 31 0;
#X connect 12 0 11 0;
#X connect 13 0 19 0;
#X connect 14 0 15 0;
#X connect 15 0 6 1;
#X connect 16 0 18 1;
#X connect 17 0 16 0;
#X connect 18 0 32 0;
#X connect 18 0 32 1;
#X connect 19 0 12 1;
#X connect 20 0 9 2;
#X connect 21 0 23 0;
#X connect 22 0 23 0;
#X connect 23 0 25 0;
#X connect 24 0 26 0;
#X connect 25 0 9 0;
#X connect 26 0 22 0;
#X connect 27 0 30 0;
#X connect 28 0 29 0;
#X connect 29 0 18 0;
#X connect 30 0 28 1;
#X connect 31 0 1 0;
#X connect 33 0 34 0;
#X connect 36 0 35 0;
#X connect 37 0 41 0;
#X connect 38 0 42 0;
#X connect 39 0 43 0;
#X connect 40 0 44 0;

Thanx for sharing. This is not Vanilla, is it? Lots of objects don’t display here. Does this compile for the OWL?

Nope. I use pd-l2ork. The knobs are from moonlib and there is a [vline~] and a [curve~] object.

I made a patch for the OWL:
https://hoxtonowl.com/patch-library/patch/Kick_Drum/
I had to remove some logaritmic functions and it doesn’t sound exactly the same, but I think it’s close enough.

Now it has MIDI input.

Nice, lovely parameter selection.
Were log functions too cpu intensive?
A word of warning about OWL Pd patches using notein: it might lead to OWL crashes if you feed it lots of concurrent messages.
I’m working with enzien on a solution.

No, I was using [log~] for the frequency decay and [curve~] for the amplitude envelope. Those objects aren’t in the heavy compiler. I just simplified things.

And yes, the OWL crashed a few times :frowning:

Oh, and I noticed a strange behavior in [+] object (I suppose in all operators). With heavy compiler, this objects don’t save the state of the inlets. Triggering the object won’t make the last operation and you need a [i] or [f] object to save the last value.
On this patch, it’s done with the [+] object before [mtof].

Thanx for the hint regarding saving last state.

Do you know the sound on sound articles about generating electronic bassdrums? They are pretty great, this one for the basics of membranophones and this one for a more practical approach including examples from fav drum machines and synths.

*Enjoy.

@JoseFuzzNo regarding notein: I think we’ve fixed the problem and you should not be seeing any more crashes: could you recompile and try it out pls?

@jayrope SOS synth secrets are awesome! I’ve heard there are plans to reissue the whole series as an ebook, which will be great.

Well, it doesn’t crash feeding a lot of messages so thats fixed, but it crashes when the message is a controller message.

oh ok, weird! Any CC will crash it? I’ll investigate…

I only did a quick test. The CC commands sent by OwlControl don’t make it crash but with my lauchpad (that sends CC 104 to 111) it did.

I’m guessing that only MIDI messages not handled by the firmware reach the PD patch and I suppose all controller messages that aren’t used by the firmware will crash the OWL. I didn’t check the heavy code for [notein] but I bet that it is a silly mistake, something like not checking if it is a 0x80-0x90 message.

[ctlin] is not supported in OWL Pd patches - yet.

All handled MIDI CC messages are listed in this file OwlWare/OpenWareMidiControl.h at master · pingdynasty/OwlWare · GitHub
(see enum OpenWareMidiControl)

It’s generally a good idea not to send the device CC messages indiscriminately as they may have unintended consequences such as mute, bypass or even factory reset.

Unhandled messages are simply ignored.

Ok, I wasn’t compiling with the last OwlProgram, don’t know why. The crashes I noticed were probably the same issue (too many messages) and I got confused. Now I have the updated OwlProgram and everything works fine. I tried sending a zillion messages with PD, and the OWL takes it just fine.

And yep, I usually don’t send garbage to the OWL. I use a PD patch that handles the routing but this time I connected the launchpad directly to the OWL.