* Home * SlinkP Software Projects
Last updated Jun 28, 2008 6:07 pm Universal

SlinkP's Code Page free software for web and for music.

What's Here:

Ongoing Projects

Script to Fix Old Ardour Sessions

Updatedd, June 2008: Old Ardour versions (0.99.something) would reference LADSPA plugins by their human-readable name. Unfortunately, the excellent CAPS plugins have been renamed several times. This script fixes the session file to use proper LADSPA ids, and attempts to update the old name too. Get it Here. BSD license, NO WARRANTY, not tested much!!

Tiny patch to decrypt_emp.pl

New, Nov 2004: Emusic's "Download Manager" sucks ass. Thankfully, there is a perl script floating about that replaces it and works fine. The latest version that works currently is at: http://www.aptalaska.net/~ben.h/emusicdlm/

But, it could do a slightly better job at catching badly-named files. Here's a tiny patch:

<                               $output_file =~ s/[ \'\!\@\#\$\%\^\&\*\(\)]/_/g if $config{CleanNames};
<                               $output_dir =~ s/[ \'\!\@\#\$\%\^\&\*\(\)]/_/g if $config{CleanNames};
>                               $output_file =~ s/[ \t\/\'\"\!\@\#\$\%\^\&\*\(\)\\]/_/g if $config{CleanNames};
>                               $output_dir =~ s/[ \t\'\"\!\@\#\$\%\^\&\*\(\)]/_/g if $config{CleanNames};

Sfront patches

New, Dec. 12 2002: I've patched sfront to enable it to create clients for JACK Audio Connection Kit. Currently, output works fine (tested mono and stereo). Input does NOT seem to work; it seems to connect but I don't hear anything. Download the patch and additional files here.


A project to allow manual synchronization of live data between two or more running instances of Zope. I inherited this from Andy McKay. Find it on sourceforge.

Old Weird Hacks and Pipe Dreams

Projects I have abandoned or never got off the ground. I wouldn't advise using any of these, except maybe as a source of ideas.


Pysco was a group of Python modules useful for computer music. It was getting just barely interesting... I've dumped it and got involved with OMDE/Pmask, see below.


Pysco evolved out of Pscore, which was a csound-score-generating module written in Perl. Pysco does everything Pscore did and more.

The only available version of pysco is very old. It is a module which can be imported into a python script. You then compose / program music in your script. There is a little sample piece ("song1.py") included with the source, which is kind of fun but is mostly just a testbed that reveals the many limitations of the current design, and some of the possibilities ahead. The curious can look at the source or listen to an MP3 of song1.py.

Current status, 11/14/02:

Well, I've pretty much tossed pysco in favor of contributing to OMDE / PMask. Haven't done much lately, but OMDE should eventually be able to do everything pysco ever did and much more.

Current Features of Pysco (very old)

  • Generate Csound note events and save to a score file.

  • unlimited separate output time-streams ("tracks")

  • unlimited simultaneous different tempos (each track can have its own tempo, including independent accelerandos / ritards)

  • unlimited named "chunks" of events

  • many functions provide automatic time updating so you don't have to count beats all the time

  • select ranges of musical chunks by beat value

  • much documentation in the source
For more information, have a look at the changelog.


  • python (www.python.org)
  • csound (www.csounds.com)
  • any operating system that both python and csound run on. This should include unix, linux, windows, mac, and perhaps others.

Download pysco.py 0.1.0

Grab it here.

Features that do or will eventually exist in OMDE / PMask:

  • High-level abstract musical data classes

  • More and better ways of selecting ranges of notes to copy, modify, delete, etc.

  • A generic output interface with sample implementations for csound and midi. Control multiple outputs from one script. Should be easy to add interfaces e.g. MP4-SA, ecasound ....

  • Handy operator overloading so e.g. event1 + event2 returns a new event equivalent to event1 followed by event2. (suggested by Eric S. Tiedemann)

  • I'm hoping to be able to run a realtime sequencer module of some sort from scores, interactively via one or more GUIs, or even via the Python interactive prompt. Initial testing suggests that Python can't natively provide accurate timing, so this will probably rely on communication with some other process, and will probably not be platform- independent. I'm looking at Midithing at http://quitte.de/midithing.html

  • Save user interaction with the sequencer for later re-use.

  • Tempo control will be both more flexible and more sensible. It will be easier to have one tempo for an entire composition, and surprisingly easy to have very complex time relatinoships.

BUT some of the above is only in the planning stages. Better download OMDE /PMasmk and see what it can do already.

SU700 tools project

I owned a Yamaha SU700 loop sampler. Got tired of it and sold it. So i've abandoned my goal to write some tools that would eventually allow me to create or modify samples and pad maps on the PC and then load them into the SU700 as if I'd created them in the SU. However, I'm leaving the stuff here in case anybody finds it useful.

So far I have a working conversion tool that can translate between WAV, AIFF, and SU700 formats. There are also many notes on the various files contained in an SU700 "volume". You can read them here.


A little Python script that lets you tap on the keyboard (console, not MIDI) and prints a tempo estimated from your taps. A toss-off that does its job, probably I won't do much more with this. updated 6/28/2008 to work on recent linux versions


Linux or some other Unix with Python installed.

Grab the source for the current version of tempotool here.


This is my hacked version of piddlePS.py where I try out my ideas for improvements. Get it here.

piddlePS is part of the PIDDLE graphics library for Python, now renamed sping. Originally, piddlePS.py created only single-page Encapsulated Postscript files, but I needed multiple-page PostScript output, so I started hacking away. Please don't try to use this for anything unless you at least know what piddle, python, and postscript are!

Note: I now use Reportlab for this kind of stuff.


A small collection of shell scripts I use a lot: aiff2wav, wav2aiff, rawplay (interactively guess the format of unknown soundfiles), alsa (kills running OSS-Linux driver and turns on ALSA), oss (like alsa only reverse), play.patch (a patch to the SoX play script that handles .mp3 and .shn files, if you have mpg123 and shorten installed). Most of these scripts require a recent version of SoX.

Download here


Pscore was the predecessor to pysco. While pysco is a python module (pysco.py), Pscore is / was a Perl module (Pscore.pm). Pscore is not being developed or maintained, and will go gracefully into that good night.

I am leaving the Pscore.pm tarball up on this page on the off chance that anyone wants to see some dumb examples of processing csound scores with perl. Do NOT download this and expect to do much that's useful with it.

To anyone considering using Perl for scripting csound scores, or other kinds of musical data, I would like to respectfully advise you to think twice about it. The reasons Perl is attractive and the reasons it will, in my opinion, bite you on the ass sooner or later, are detailed on a webpage titled What's Wrong with Perl.

Obviously I'm biased, and I never did get to be much of a Perl wizard, but I've found it much easier and more fun to tap the power of Python.

The truly perverse can download Pscore.pm here.


An old, no-longer-maintained utility for controlling the surround-sound and S/PDIF output on a CS-4237B soundcard (e.g. the Turtle Beach Malibu). This was necessary because OSS-Free and OSS-Linux drivers didn't support these features; but ALSA now does, so I don't use dspctrl any more. But occasionally people ask me about it, so here it is.

freeverb opcode for csound

This was my first (last?) attempt at hacking a csound opcode. "Hacking" is really the right word; I got far enough to get it to compile and I can now use freeverb in csound orcs, but it doesn't sound right at all, and I have no idea what to do next. I'm ready to turn this project over to someone else.

Update: Similar functionality was added to one of the csound core reverb opcodes, I forget which one, and it sounds about the same as mine :-\ I think

If you don't know, freeverb is a public-domain implementation of a Moorer-type reverb, with a bank of 8 comb filters feeding 4 allpass filters in series. Jezar, the author, spent a lot of time tuning the filters and his work paid off very nicely; it is a very smooth-sounding reverb.

Jezar's Freeverb README claims that it's just his patiently tuned settings for the comb and allpass filters that make Freeverb sound unusually good. So I just copied the frequency settings from his tunings.h and fed them into a hacked version of Paris Smaragdis' reverb2 opcode, which seemed to have the right design - I just changed it from 6 to 8 combs and from 5 to 4 allpass. (Note that reverb2 was unmodified and should still work.)

After much swearing trying to get the damn thing to compile, I finally fixed all my stupid blunders and got a csound that compiles and runs. And of course it sounds nothing like Jezar's Freeverb. Most notably, there's quite a bit of weird high-end ringing going on. Changing the damping parameter does change the sound but never gets rid of the ringing. It may have something to do with the filter gains and/or damping control. It also may have to do with Jezar's odd comb filter code, which is quite unlike the filters in csound - it seems to have built-in lowpass filtering. But I don't really understand either freeverb or reverb2, so I gave up.

NOTE: There is now a reverb opcode that comes with csound that sounds almost exactly like my hack and claims to have taken its filter tunings from freeverb. I forget which opcode. This supports my hypothesis that the comb and/or allpass filters are implemented too differently.

Anyway, Here is my patch against unofficial Linux csound version

Here is a test orc and sco. Obviously you'll want to replace the soundfile in instr1.


OK, so Smake isn't even vaporware yet. It's just an idea I had April 20, 2000, and there's no code at all ... but here's the idea anyway.

So I'm sitting here avoiding work at the last minute reading csound mail, when somebody mentions using make to manage large csound projects. That's something I'd thought of before, since I use make to manage my band's website....

It occurred to me that a project management system like make is a really overlooked tool for a computer-based music workstation. You can do a lot of musical work with GNU make as it stands, but I think that specializing the idea a bit for music, and integrating it into a sound clip mixer, could be a really fruitful idea.

We have all these cool scriptable tools available for linux audio: soft-synths (csound, cmix, tao ...), effects processors (ecasound, cmix, even sox), mixers (ecasound & cmix again), etc. They are all useful and have unique strengths. Tying it all together can be a real pain in the ass.

So I'm imagining a visual interface somewhere between a mixer / "clip sequencer" (think Protools, Nuendo, even Mix...) and a project manager.

So here's an ugly gimp mockup that gives a vague idea of what's in my mind.

a really ugly mockup

OK, this mockup sucks. For one thing, the dependency lists would probably fit better if they were much taller and narrower.

Basically this is like a typical non-linear audio clip mixer / editor. The main part of the window shows audio clips placed in time. (These are the plain colored bars in my mockup; these might eventually become waveform displays, or not.) Clips could actually be non-audio data such as MIDI files or csound scores. You can drag them around, cut, copy, and so forth. You can draw and drag breakpoint graphs for parameters - volume, pan, whatever. These parameters are used to generate an edit list for the mixing engine (which could be anything suitable: ecasound could do it, so could csound...).

(Note: There could be two kinds of mix automation graphs: anchored to clips, and anchored to tracks. Graphs anchored to a clip would be moved along with the clip if you move or copy that clip. Graphs anchored to tracks would stay put when moving clips around. I need to come up with a clear visual representation of this distinction.)

What's unique about Smake is that each clip in the display is really a "target": it has dependencies, just like in a Makefile. For instance, if a sound clip is produced by a particular csound orc and sco, then it depends on them, and when you hit the big "Make" button, it will be re-compiled if the orc or sco has changed.

Just like in GNU make, dependencies can themselves be targets. So if you select a target that depends on other targets, the display would "descend" into that target; it would become the new top-level object and you would see what it depends on, etc.

Also like with GNU make, if no dependencies have changed, doing "make" will cause nothing at all to happen; if any dependencies have changed, only the targets that depend on them will be updated. If some of your targets are soundfiles that take 10 minutes for csound to produce, you'll be really glad if they are only rendered when necessary! This saves you the time of unnecessary rendering, and the hassle of remembering which things you need to update by hand!

Another benefit pointed out to me by Richard W. Furse: you could have the traditional "make clean" target which prunes your files down to the bare minumum needed to re-create the composition. This could save a lot of disk space and provide a nice compact form of the work to save as a backup.

There should also be a "tree" view of dependencies. Colors could be used to highlight which targets are up to date, which are not, and which dependencies have changed.

Oh yeah, you should also be able to configure smake so you can fire up your favorite "editor" for each type of dependency. For example, if you created a WAV file with the GreenBox drum machine, you could have that WAV file depend on the GreenBox "save state" file which, when clicked on, pops up GreenBox. Cool!

Flash thought: Smake could be implemented in Pysco!

     Send me some mail slinkP home page Powered by Zope