iOS distribution provisioning


While preparing an upgrade for audioGraph today – ran into problems trying to upload and validate the binary (via archive in xcode 5)

The answer:

  • create a new distribution provisioning profile, after registering the upgrade in itunes connect.
  • download the profile and drag into xcode.
  • follow the instructions on this stack overflow post

Also – there were issues with icons. You need to assign the filenames in the .plist file

Repurposed transmitters


Other possibilities:

  • Microwave ovens
  • Key fobs
  • Cordless phones
  • Wifi access points
  • prepaid analog cell phones


rtlsdr, Pd, linux


Today was able to get the rtlsdr~ object running in Pd on Ubuntu 14.04 on a Macbook pro.

Audio quality seems rough. The only driver I could get to work was Alsa at 44.1KHz – may be able to get help with this from Pd community.

Ended up using 64bit libraries for librtlsdr and libusb-1.0 . In fact, needed to using the shared (.so) libraries, not the static ones (.a) due to a weird linker error. Its possible that it happened due to mixing shared and static and I might try again using both static for these 2 libs.

See notes from previous post about issues with USB capture, and non-root user in Linux – there are 2 flags on the cmake for rtlsdr that might help resolve both of these, but I wasn’t having any luck and needed to use the method described in previous post.

The source code for linux version is in the /usr/lib/pd-extended/extra/rtlsdr~ folder – and the test pd file is in ~/pd/rtlSDR-block.pd, along with some abstractions.

There is also a makefile to build a local version of rtl_fm (rtl_fm3.c) in ~/rtl-sdr-new/rtl-sdr/rtl-fm3/

This makefile mixes the static and shared libs with no problem… hmm…?


Need to package this stuff up and send it to pdsdr github with source for Max/Pd on mac and Pd on linux. + instructions… etc.,

Would like to try running on r-pi – but will need to adapt the test patch to receive Osc messages because there is no gui on r-pi

Also I am some skeptical about running at low sample rates for audio – we’ll see…

another note

Just thinking, that even if I am not able to run rtlsdr~ on r-pi that we could adapt rtl_fm so it receives control input from Pd using Osc and work that way…


rtlsdr – Ubuntu installation

Notes for Ubuntu 14.04 LTS

Basic install:

1. use instructions at

You will also need to install the following dependencies:

  • git
  • cmake
  • make
  • libusb-1.0
  • sox (optional)

Two issues:

  • rtlsdr device gets captured by OS, preventing application access
  • Standard installation process doesn’t allow non-root users to use a device

To prevent OS from capturing device…

Set up a blacklist file as explained in this post:!msg/ultra-cheap-sdr/6_sSON94Azo/sOkhU81YINIJ

As the message suggests, there are two solutions.  The quickest is to
simply unload the driver:

sudo rmmod dvb_usb_rtl28xxu rtl2832

Not sure whether “rtl2832” on the end there is required or not, but it
can’t hurt.  This is only a temporary solution, as the driver will be
loaded again the next time you unplug and replug the USB device, so
you’ll have to run the command again.

If this works, and you don’t want to use the device for TV reception,
you can stop the module from ever being loaded, solving the problem
permanently.  The exact method depends on your Linux distribution, but
for me (running Arch Linux) I create a file in /etc/modprobe.d with
a .conf extension (I called it “no-rtl.conf”) with these contents:

blacklist dvb_usb_rtl28xxu
blacklist rtl2832
blacklist rtl2830

Again not sure whether it’s necessary to blacklist all three of these
or just the first, but I was erring on the side of caution and chose to
list everything to do with the Realtek DVB device.

Once you have created this blacklist file, you may need to unload the
driver one last time if it was already running – the blacklist
prevents it from loading but doesn’t do anything if it’s already

To allow non-root users to use the device…

Set up a udev rule as explained in this post:

Next, you need to add some udev rules to make the dongle available for the non-root users. First you want to find the vendor id and product id for your dongle.

The way I did this was to run:


The last line was the Realtek dongle:
Bus 001 Device 008: ID 0bda:2838 Realtek Semiconductor Corp.

The important parts are “0bda” (the vendor id) and “2838” (the product id).

Create a new file as root named /etc/udev/rules.d/20.rtlsdr.rules that contains the following line:

SUBSYSTEM==”usb”, ATTRS{idVendor}==”0bda”, ATTRS{idProduct}==”2838″, GROUP=”adm”, MODE=”0666″, SYMLINK+=”rtl_sdr”

With the vendor and product ids for your particular dongle. This should make the dongle accessible to any user in the adm group. and add a /dev/rtl_sdr symlink when the dongle is attached.

It’s probably a good idea to unplug the dongle, restart udev (sudo restart udev) and re-plug in the dongle at this point.




Notes: Chatbots in Conversation

update 6/2014 – Now part of the Internet sensors projects:

original post

They can talk with each other… sort of.

Last spring I made a project that lets you talk with chatbots using speech recognition and synthesis.

Yesterday I managed to get two instances of this program, running on two computers, using two chatbots,  to talk with each other, through the air. Technical issues remain (see below). But there were moments of real interaction.

In the original project, a human pressed button in Max to start and stop recording speech. This has been automated. The program detects and records speech, using audio level sensing. The auto-recording sensor turns on a switch when the level hits a threshold, and turns off after a period of silence. Threshold level and duration of silence can be adjusted by the user.  There is also a feedback gate that shuts off auto-record while the computer is converting speech to text, and ‘speaking’ a reply.

technical issues

  • The Google speech API has difficulty with some of the voices used by the Mac OS speech synthesizer. We’ll need to experiment to find which voices produce accurate results.
  • The overall levels produced by the builtin Macbook speakers is not quite enough to achieve clear communication. The auto-recorder missed the onset of speech sometimes. One solution would be to insert a click to trigger the recorder, just before the speech synthesizer begins the actual speech. Or to use external speakers, or a secondary “wired” connection.
  • It would be nice to have menus of chatbots and voices. Also to automate the start of a new conversation thread.
  • The button to start the audio detector had to be operated by key-press because pushing the trackpad on a MacBook makes too much noise and always triggers the audio level detector.
  • Occasionally a chat bot would deliver a long response, or one containing a web address. These were problematic for recognition and synthesis.

local files

  • tkzic/internetsensors/speech-to-google-text-api3.maxpat
  • tkzic/internetsensors/pandorabots-api2.maxpat
  • tkzic/internetsensors/text-to-speech3.maxpat


RTTY at 300+ bps in Max


After a few vexing timing issues I have been able to send and decode RTTY (technically AFSK audio frequency shift keying ) in Max at 300 baud. Click hear to listen to an example of a 13 word message at 300 bps (300 baud)

The js object adds significant delays (on the order of a few milliseconds) – so I replaced the encoder with a coll and that cleaned up the timing problems when encoding. This patch demonstrates the issue:

Also… You can use threshold~ instead of snapshot~to feed binary pulse amplitude detection logic into edge~ – but you need to run the signal through average~ to prevent the amplitude from repeatedly dropping to zero at the signal frequency. Like this:

Is it better than snapshot~? it seems to be, but who knows – at these speeds it would probably be better to write the whole thing in gen~

There are a few other things – like using counter~ instead of phasor~ to drive the decoder clock. This allows you to restart the clock, when the onset of the start bit is detected – and you can add a variable amount of delay to find optimal point in the signal vector to read the pulse. At 300 bps, at 96k SR, each pulse is 320 samples (3.1 milliseconds) –

I’ll write more on this later –

The Katja Vetter article on Beat-Slicing was helpful – along with several Max tutorials on Audio control rates, and envelope followers.

Local Patches are in;

tkzic/ max teaching examples/

  • rtty-send10.maxpat
  • rtty-recv9a.maxpat