Month: December 2013

Programming Electronic Music in Pd

By Johannes Kreidler.

An amazing resource for Pd programming, with downloadable examples.


Pd was initiated by American software engineer Miller Puckette, who previous co-developed the well known and similarly structured software Max/Msp. Pd is not commercial software; i.e., it was not developed by a corporation and is not for sale. Instead, it is “open source”: its source code is not the (patented) property of a corporation, but is rather freely available to all. One drawback to this is that a detailed operating manual for users who lack programming experience has not existed until now. In contrast to a corporation— which has a monetary interest in ensuring that first-time users can easily operate new software—the open source movement lacks such a driving force to make itself accessible. This book is an attempt to fill that gap.

This tutorial is designed for self-study, principally for composers. It begins with explanations of basic programming and acoustic principles then gradually builds up to the most advanced electronic music processing techniques. The book’s teaching approach is focused primarily on hearing, which we consider a faster and more enjoyable way to absorb new concepts than through abstract formulas.

The patches described are available for download.


Facebook key loggers

This topic came up at Christmas dinner with the relatives…

If Facebook is really key-logging rather than just collecting posted data, then would it be possible to overwhelm the key-loggers by building algorithmic typing devices (ie., keyboard simulators) which ran in the background – and then offer them as free Facebook add-ons?

That is if anyone still uses Facebook…

By Jemima Kiss at The Guardian

near-ultrasound data transfer in Max using FSK (rtty)

An example of sending data through the air, from one computer to another, using sound. The carrier frequency – 18Khz – just below ultrasound, is inaudible to most humans. The data protocol is Audio Frequency Shift Keying (AFSK) at 45 bits/second. It uses two tones – to encode 1’s and 0’s. This protocol was developed for radio teletype (rtty).

One computer sends the word “hello” to the other computer every 10 seconds.

The idea came from a paper by Michael Hanspach and Michael Goetz – “On Covert Acoustical Mesh Networks in Air” – In the paper they explain that the concept was borrowed from current technology for underwater data networks. They warn of the vulnerability of “air-gapping” as a method of computer security.

Actually, after watching the video I realized its difficult to make exciting videos that feature sounds you can’t hear. Especially when you are whispering. Well, the pro camera crew should be knocking on the door at any moment.


folder: frequency-shift-keying


  • rtty-recv12.maxpat
  • rtty-send12.maxpat
javascript files:
  • rtty-encode10.js
  • rtty-recv9.js


To run patches:

  • in rtty-send12 set carrier frequency to something like 200
  • then toggle start/stop
  • You may want to increase the speed to 32
  • On the receive side, clear the text box
  • Make sure to set audio as described below

In audio settings try

  • io vector = 512,
  •  signal vector = 32,
  •  overdrive and audio-interrupt should be enabled,
  •  SR=96 Khz.

Interesting discovery – or maybe a coincidence. Bit rates which are powers of 2 seem to work way better than arbitrary speeds.  I wonder if its because the signal vector size is also a power of 2?

Going from a direct audio connection to an through-the-air connection led to a number of issues with filtering and and levels.  The latest version of the Max patches have been organized into modules, like: encoder, transmitter, decoder, phasor-clock, etc., But they would benefit from some encapsulation.

It was interesting that throughput was better above 14Khz. Possibly due to less interference from environmental sounds – and less critical filtering. During the video I was able to talk (whisper), without interfering  with data transfer. But if I squeaked a chair or tapped the desk, it would screw-up. Also, the builtin mic/speaker on MacBooks have response curves that are all over the place.

The next version will have sharper filters and an automatic level control (compressor).  There’s  difficult interaction in the detection process between filtering and timing. Up to this point I’ve been reluctant to use frequency domain filtering due to loss of timing resolution. Latency is ok though. But the other thing is that we don’t want filters which soften or distort the shapes of the pulses.

So one question is how high can you go – with the built-in mic and speaker. They are not rated above 20 Khz. but you never know?