But rather than a Python library, its a very nice “little-language”, with great operators for describing composition of data-flow blocks. It’s well developed and supported. I’m trying it out for writing small synths / FX units I can run on small boards like CHIP and Raspberry Pi.

I can see myself doing a lot with this. But it’s basically going to kill Gates of Dawn. Maybe there’s room for a Python library for those who don’t want to learn Faust. But for me, Faust is looking extremely viable.

So … another wasted project?

Perhaps I need to look at this positively. I’m not old. But I’m not as young as I used to be. I don’t have so many projects left ahead that I can afford to squander them. Perhaps its time to pivot. Time for a cull. A “spring-clean”. To remove some more cruft projects that occupy too much of my mind, but are actually just weak “me-too” versions of existing things that I would use perfectly happily if I made the effort to learn them. Enough with the Not Invented Here syndrome.

I’m not saying that OWL or MTC are going anywhere yet. I use them, and they work for me. And they are DIFFERENT from OrgMode, or todo.txt or any similar thing out there. They are what I want.

But I need to embrace this change. There are so many exciting NEW opportunities, there’s no point getting hung up on the old stuff.

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.

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.)

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 :

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.