for some time now, i've been interested in the work of howard t. odum, zoologist and pioneer in the field of systems ecology. h. t. odum's goal was to derive a language for the transformation of energy into different forms, which could represent such transformations as edges in a network.his notational system, called "energy circuit language", borrows from other systems theory notations such as forrester diagrams or electrical schematics, but diverges from such systems in an attempt to describe systems in even more general terms. h. t. odum spent years honing this language by attempting to model the data he and his brother eugene odum, a zoologist and ecologist as well, collected from various ecosystems. the two brothers are ostensibly responsible for the modern conception of the term 'ecosystem' itself.

prior to the advent of microcomputers, h. t. odum implemented his models using analog computer components like logic gates and op-amps. with a little help from my friends, i have begun recreating some of his circuits, in hopes of building an ecological modular synthesizer. more on that later...

when such technology matured, microcomputers became odum's prefered tool of choice for testing his models. digging through his oeuvre, i found numerous models of systems at many scales implemented as routines in the BASIC programming language. in order to provide myself and my colleagues with a reasonable idea of the project we are undertaking by reproducing his analog circuits, i have implemented a few of these routines as external objects for the PureData realtime synthesis environment.

despite their superficial similarities, energy circuit language and puredata are different in extremely important ways. first of all, in odum's system, edges may be weighted, with weights corresponding either to linear scaling or probability. however seemingly trivial this distincion may be, an even more instrumental caveat is how the two systems handle feedback. in puredata, feedback must be created with a minimum delay of a block size. this size can be reduced using the block~ object, but at a significant cost to efficiency. my solution was to implement entire subsystems in the dsp routine of an object, thereby allowing for arbitrarily small feedback latency (down to a single sample, at least). this single sample limit, as it turns out, a source of error in many discrete-time modelling schemes, is perhaps best circumvented by a continuous-time implementation, which is on its way. nevertheless, these puredata externs have allowed us to experiment with sonification and scaling methods.

in this package i have included the puredata externs (compiled for 32-bit linux platforms), the sourcecode, and demonstration patches for the following objects:

comparator~ , a dsp-rate comparator which returns high if the right inlet is lower than the left, and low otherwise

tank~ , a dsp-rate model of a leaky storage unit, a basic component in energy systems language

war~ , a dsp-rate model of two nations at war. this is by far the most complex extern in the package. the coefficients (message-rate) relate to the following diagram, reproduced from odum, 2000 (click for larger view):

the patches included are meant for demonstration purposes only. in fact, with the exception of war_test.pd, they do not produce sound. i recommend the use of an oscilloscope to fully appreciate them. unless you can hear dc, in which case, we need to talk...

The blog that linked to my post incorrectly credits one of my own drawings as a diagram from Odum's notes. Still an interesting read...