Sporth and Pure Data. Pure Data and Sporth.

2017-07-01

Today I thought I'd talk a little bit about my efforts in getting my audio language Sporth and Pure Data to work together. This post will describes my pd external for Sporth, as well as my more recent efforts in getting PD patches to run inside of Sporth.

Background and Motivation

For those who don't know, PD is a visual programming language by Miller Puckette. Programs are made by connecting blocks together. PD is a very popular free alternative to the commercial software Max/MSP (which Miller also created while at IRCAM.) It is an environment intended for composers and multimedia artists. Pure Data has two concurrent versions that are developed: "vanilla" and "extended". The vanilla version is developed by Miller Puckette himself, and the extended version is a fork built on top of PD vanilla with a reworked GUI and a bunch of nice built-in extensions and plugins. The focus of this blog post will be on vanilla pd, and not pd-extended.

Traditionally, I've never really understood the hype about visual programming interfaces. They are very mouse-driven interfaces, and I find the mouse to be a very clumsy means of interacting with computers (the touch screens found on phones and tablets, on the other hand, are very intriguing to me). Compared to text-based languages, PD and Max were always slow for me to work in. The patch cable paradigm, while cute for small and simple patches, always turned into a nightmare for more complicated patches.

More recently, things like Apple Playgrounds and some of the work by Bret Victor have made me warm a little bit to the idea of introducing visual elements into traditional text-based means of programming. For creative sound design, it is very nice to have UI elements and visualizers for feeling out the behavior of particular synth patch. Visual elements also provide a really nice means of organizing information. Even something like rich formatted text in literate programming can really be a huge step from from just plain code.

Sporth inside of PD

About a year ago, I made it possible to run Sporth patches inside of PD as a PD external. This project is part of the Sporth code distribution, located in /util/pd/. My initial motivation for making this was for demo purposes; knobs and sliders are far more engaging than just sporth code by itself.

The Sporth PD external could do things like compile/recompile Sporth files and read/write to p-registers. The Sporth API made it trivial to spawn multiple instances of Sporth in a single patch (take that ChucK and PD!).

A few days ago, I made it possible get the external to compile strings from inside the patch, rather than from an external text file. This made a few things easy. Firstly, removing the need for external files made it much easier to distribute. Secondly, multiple instances of Sporth could be used together in a very easy way:

.

Instead of having to recompile the entire Sporth patch, individual segments could be chunked and recompiled separately as needed.

PD inside of Sporth

I've been recently interesting in leveraging PD in my work. While I do quite enjoy working in Sporth environment, I will concede that there are some performance limitations to Sporth's naively created structure. PD, on the other hand, was created by someone much smarter myself, and I believe the audio graph used for signal processing to be better than the linked-list stack-based system Sporth uses.

These motivations have lead me to make sporth-pd, a Sporth plugin that compiles a PD patch (read-only) and computes the audio from it from inside of Sporth. This plugin is limited to only PD instance per Sporth patch. One has the ability to load patches that contain PD externals. Because of this, it is indeed possible to load Sporth from PD, from inside of Sporth. This feature has also motivated to me to begin building my own PD externals using Soundpipe directly.

A popular way to embed PD inside of applications is through libpd. For my needs, I found libpd distribution to be far too bloated for my needs. Using the libpdwrapper code as a reference, I used the PD api directly to build my Sporth plugin. I also decided to include PD as a submodule in the project, so I could compile a minimal local version of PD. I have tried to reduce the dependencies as much as I can, but I have unable to get rid of the portaudio depdendency, even with the dummy audio flags (UPDATE: since writing this blog post, the portaudio dependency has been removed. Yay!).

Future plans

As I learn more about how to actually use PD, I hope to better solidify the relationship between itself and Sporth. I also want to someday be able to somehow get Spigot and PD talking to one another, and perhaps get Spigot running inside of PD somehow.