I’ve gone back to doing some work on Gates of Dawn, my terse Python library for creating PureData patches.
The idea here is I want to make synthesizers in PD but I don’t particularly like drawing boxes and connectors using the clunky UI.
Here’s a brief overview from the Readme file. Showing some simple code examples and introducing the key ideas.
Idea #1 : Gates of Dawn uses function composition as the way to wire together the units in Pure Data.
In PureData traditionally, you’d do something like wire the number coming out of a slider control to the input of an oscillator and then take that to the dac audio output. Here’s how to express that using Gates of Dawn.
dac_ ( sin_ ( slider("pitch",0,1000) ) )
To create the slider you call the slider function (giving a label and a range). Then you pass the result of calling that as an argument to the sin_ function (which creates an osc~ object in PD). The output of that function is passed as an argument to the dac~. (Note we are now trying to use the convention that functions that represent signal objects (ie. those that have a ~ in their name in PD) will have a _ suffix. This is not ideal but it’s the best we can do in Python.)
In Gates of Dawn programs are structured in terms of a bunch of functions which represent either individual PD objects or sub-assemblies of PD objects. You pass as arguments to the functions those things that are upstream and coming in the inlet, and the return value of the function is suitable to be passed to downstream objects.
Things obviously get a bit more complicated than that, but before we go there, let’s just grasp the basic outline of a Gates of Dawn program.
Idea #2 : Files are managed inside with patch() context blocks.
Here’s the complete program.
from god import *
with patch("hello.pd") as f :
dac_ ( sin_ ( slider("pitch",0,1000) ) )
We use Python’s "with" construction in conjunction with our patch() function to wrap the objects that are going into a file. This is a complete program which defines the simple slider -> oscillator -> dac patch and saves it into a file called "hello.pd"
Try the example above by putting it into a file called hello.py in the examples directory and running it with Python. Then try opening the hello.pd file in PureData.
If you want to create multiple pd files from the same Python program you just have to wrap each in a separate with patch() block.
Idea #3 : Variables are reusable points in the object graph.
This should be no surprise, given the way function composition works. But we can rewrite that simple patch definition like this :
s = sin_ ( slider("pitch",0,1000) )
dac_(s)
The variable s here is storing the output of the sin_ function (ie. the outlet from the oscillator). The next line injects it into the dac.
This isn’t useful here, but we’ll need it when we want to send the same signal into two different objects later on.
NB: Don’t try to reuse variables between one patch block and another. There’s a weird implementation behind the scenes and it won’t preserve connections between files. (Not that you’d expect it to.)
Idea #4 : Each call of a Gates of Dawn function makes a new object.
with patch("hello.pd") as f :
s = sin_ ( slider("pitch",0,1000) )
s2 = sin_ ( slider("pitch2",0,1000) )
dac_(s,s2)
Here, because we call the functions twice, we create two different oscillator objects, each with its own slider control object.
Note that dac_ is an unusual function for Gates of Dawn, in that it takes any number of signal arguments and combines them.
Idea #5 : You can use Python functions to make cheap reusable sub-assemblies.
Here’s where Gates of Dawn gets interesting. We can use Python functions for small bits of re-usable code.
For example here is simple function that takes a signal input and puts it through a volume control with its own slider.
def vol(sig,id=1) :
return mult_(sig,num(slider("vol_%s" % id,0,1)))
Its first argument is any signal. The second is optional and used to make a unique label for the control.
We can combine it with our current two oscillator example like this :
def vol(sig,id=1) :
return mult_(sig,num(slider("vol_%s" % id,0,1)))
with patch("hello.pd") as f :
s = vol (sin_ ( slider("pitch",0,1000) ), "1")
s2 = vol (sin_ ( slider("pitch2",0,1000) ), "2")
dac_(s,s2)
Notice that we’ve defined the vol function once, but we’ve called it twice, once for each of our oscillators. So we get two copies of this equipment in our patch.
Of course, we can use Python to clean up and eliminate the redundancy here.
def vol(sig,id=1) :
return mult_(sig,num(slider("vol_%s" % id,0,1)))
def vol_osc(id) :
return vol( sin_( slider("pitch_%s"%id,0,1000) ), id)
with patch("hello.pd") as f :
dac_(vol_osc("1"),vol_osc("2"))
Idea #6 : UI is automatically layed-out (but it’s work in progress).
You’ll notice, when looking at the resulting pd files, that they’re ugly but usable. Gates of Dawn basically thinks that there are two kinds of PD objects. Those you want to interact with and those you don’t. All the objects you don’t want to see are piled up in a column on the left. All the controls you need to interact with are layed-out automatically in the rest of the screen so you can use them.
This is still very much work in progress. The ideal for Gates of Dawn is that you should be able to generate everything you want, just from the Python script, without having to tweak the PD files by hand later. But we’re some way from that at this point. At the moment, if you need to make a simple and usable PD patch rapidly, Gates of Dawn will do it. But it’s not going to give you a UI you’ll want to use long-term.
Idea #7 : You still want to use PD’s Abstractions
Although Python provides convenient local reuse, you’ll still want to use PD’s own Abstraction mechanism in the large. Here’s an example of using it to make four of our simple oscillators defined previously :
with patch("hello.pd") as f :
outlet_ ( vol_osc("$0") )
guiCanvas()
with patch("hello_main.pd") as f :
dac_(
abstraction("hello",800,50),
abstraction("hello",800,50),
abstraction("hello",800,50),
abstraction("hello",800,50)
)
In this example we have two "with patch()" blocks. The first defines a "hello.pd" file containing a single vol_osc() call. (This is the same vol_osc function we defined earlier.)
Note some of the important extras here : * outlet_() is the function to create a PD outlet object. When the hello.pd patch is imported into our main patch, this is how it will connect to everything else. * You must add a call to guiCanvas() inside any file you intend to use as a PD Abstraction. It sets up the graph-on-parent property in the patch so that the UI controls will appear in any container that uses it. * Note that we pass $0 to the vol_osc function. $0 is a special variable that is expanded by PD into a different random number for every instance of a patch that’s being included inside a container. PD doesn’t have namespaces so any name you use in an Abstraction is repeated in every copy. This can be problematic. For example a delay may use a named buffer as storage. If you import the same delay Abstraction twice, both instances of the delay will end up trying to use the same buffer, effectively merging the two delayed streams into one. Adding the $0 to the beginning of the name of the buffer will get around this problem as each instance of the delay will get a unique name. In our simple example we don’t need to use $0. But I’ve added it as the label for our vol_osc to make the principle clear.
The second "with patch()" block defines a containing patch called hello_main.pd. It simply imports the hello.pd Abstraction 4 times and passes the four outputs into the dac_.
Note that right now, layout for abstractions is still flaky. So you’ll see that the four Abstractions are overlapping. You’ll want to go into edit mode and separate them before you try running this example. Once you do that, though, things should work as expected.
