soundscrape

sharing and hacking

This reference is for Soundscrape (version 0.0.0.1, last updated 03 December 2003), a programmatic synthesis environment.

Copyright © 2003 Andy Wingo

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, Front-Cover Texts, or Back-Cover Texts.

You can find more information about this license, and the license of Soundscrape itself, at the end of the manual.

Table of Contents

1. LADSPA integration

2. sharing and hacking

   1. copying soundscrape

   2. copying the manual

LADSPA integration

Supporting LADSPA plugins is a bit tricky, for a number of reasons.

There are no standard naming conventions for the plugins and their ports.

Soundscrape hacks around the naming conventions by (1) defining functions to transform names to something more soundscrape-friendly, and (2) compiling a list of known problem names with corresponding replacement values.

The order of the ports within the plugin may not be well-suited to positional arguments.

For now, just use keyword arguments when it's more convenient.

There are some plugins which are not relevant at all, given soundscrape's design.

Soundscrape compiles a list of irrelevant plugins. If you have one that you feel should be added to or taken off this list, please let the author know.

Some plugins don't have sensible default values.

Soundscrape can compile a list of sensible port default values, but it would be better at some point in time to use the LADSPA RDF library to get these values from data already on the user's system.

There is no runtime documentation available for specific plugins.

For now, the user must just know where to look to find documentation. For example, plugins from Steve Harris are documented in his source and at "http://plugin.org.uk/. Plugins from the Computer Music Toolkit (CMT) are documented at http://www.ladspa.org/cmt/. Plugins from the Bandlimited Oscillator Plugins (BLOP) are documented at http://blop.sourceforge.net/. Et cetera.

Using the LADSPA RDF library can help in this regard as well.

There might be more than one plugin implementing the same kind of operation in different ways depending on the types of the inputs and outputs, something that soundscrape abstracts away from the user.

Having more than one plugin of a different type is a problem that soundscrape solves by looking at the plugin names. For example, take sine-faaa, sine-fcaa, sine-faac, and sine-fcac. All are sine waves, but their inputs are different combinations of audio and control rates. Soundscrape assumes that if the plugin name has a character-code suffix where first letters of input ports are paired with either a for audio or c for control, the proper plugin is chosen at runtime. Consider what is printed out when you evaluate delayorama, a multitap delay line:

ss> delayorama
#<<sselement> <ssl-delayorama> 41013650>

We see a text representation of the class object, delayorama. Now do the same for sine:

ss> sine
(#<<sselement> <ssl-sine-faaa> 41017c00>
 #<<sselement> <ssl-sine-fcac> 41017520>
 #<<sselement> <ssl-sine-faac> 410172d0>
 #<<sselement> <ssl-sine-fcaa> 41017130>)

We see that there are actually four class objects listed, one for each implementation. As mentioned above, the proper one is chosen at runtime.

There might be LADSPA ports on a plugin which duplicate the default :mul and :add inputs.

In sine, "Amplitude" has the same meaning as soundscrape's :mul input. Clearly, for efficiency reasons, we want to use the version provided by the plugin, but for consistency we want to keep the standard port name, :mul. It's a bit tricky to get that right, but that's what is done. Soundscrape keeps a list of equivalent ports; any additions to the list are welcome.