Algorithmic Composition, Data Transcoding, Physical Models

We did a quick review of basic algorithmic composition techniques as a prelude for a discussion of data transcoding (the trendy term that means the use of data from one domain in another -- i.e. New York Stock Exchange data could be use to determine the pitch and/or other parameters in music synthesis). We also reviewed sverel interactive physical model max/msp objects from the PeRColate object library. We then employed physical models in a data transcoding framework.

Links

We have covered some algorithmix programming approaches in several of our earlier classes. You may want to review the [rtcmix~] patch in:

week3b

in particular. Also, former CMC denizen Chris Bailey wrote an excellent tutorial on algorithmic programming a few years back:

Introduction to Writing Algorithms (in MINC)

Some of the information is a bit dated in Chris' tutorial, but the basic concepts are all still valid.

Finally, you may want to access some of the physical model links in the week7a class.

In discussing data transcoding, Jason showed a lot of snazzy links to different datasets on the web. Here are a few:

Andrea Polli Atmospherics data
-- used by media artist Andrea Polli in a nifty "auralization" work
Historical Stock Data -- NYSE ups and downs...
Statlib Datasets Archive -- lots of strange and wonderful collections of data here

Jason also mentioned a few other sites of interest for hard-core data transcoders:

International Conference of Auditory Display -- ICAD, probably the best source of audio auralization/sonfication info
ICAD NSF Report -- instructive reading about the possibilities of auralization/sonification
Andrea Polli's Datareader -- an easy way to get data into a max/msp patch (OSX only, I'm afraid)
The Secret Life of Numbers -- Golan Levin's fun use of numbers

Applications and Examples

Algorithmic composition and data transcoding examples from class:

week7b-examples.sit -- StuffIt archive with the class max/msp and rtcmix patches

individual patches as text files (for Windows users)
- algo-demo.txt
- DIJA.txt
- algo-demo.sco
- DJIA_close.txt
- DJIA_high.txt
- DJIA_low.txt
- DJIA_volume.txt
  
  NOTE: the "algo-demo.sco" file contains the rtcmix script used in the "algo-demo.txt" patch, and the "DJIA_close.txt", "DJIA_high.txt", "DJIA_low.txt" and "DJIA_volume.txt" files contain data (for auralizing!) used in the "DIJA.txt" patch. You will need to download all of these.

One of the things I don't think we've made explicit in touching some basic algorithmic programming issues using [rtcmix~] is the structure of the RTcmix scripts that schedule notes and events algorithmically. The layout of these scripts is fairly standard -- you start with an initialization section where you set the starting values of any variables you plan to use. Notice in the RTcmix scripts that we don't declare or 'type' variables (i.e. you don't say "int varname" or "float varname" to create a variable; you just start to use it). RTcmix does typing/conversion for you automatically, unless you want to specify a type. Then you can. Also in this init section are statements such as makegen(1, 24, 1000, ...) and any other set-up information for the RTcmix instrument(s) being used in the script.

The second part of these scripts is the run loop or the part where you actually do the algorithmic thang. To do most anything you want to do in programming, you need to be able to do something over and over and over (iterating) again, possibly changing the values of certain parameters each time. We accomplish this in RTcmix scripts using the construction:

	for(var = 0; var < 14; var = var + 1)
	{
		stuff gets done in here...
	}

The thing called "var" could be any variable name, and the numbers used in this "for" loop (var < 14, var + 1) could also be anything. In the above situation, the stuff gets done in here... statement -- anything between the open-curly-brace ("{") and closed-curly-brace ("}") -- would happen 14 times, as "var" gets moved up by 1 each time (starting at 0). Note the use of semicolons (";") in the above, more on this later.

In addition to looping, it's important in algorithmic composition to be able to make decisions based on current information/context/whatever. This is so easy! in RTcmix scripts. Just say:

	if (something < somethingelse)
	{
		do something completely different!
	}

	if (something > somethingelse)
	{
		do something completely different!
	} else
	{
		face the existential void...
	}

How these operate should be obvious. One quick comment: the RTcmix language has a fairly C-like (i.e. like the "C" programming language) syntax. In "if()" statements, the comparators are less-than ("<"), greater-than (">"), less-than-or-equal-to ("<="), greater-than-or-equal-to (">="), equal-to ("=="). Note the use of the double 'equals' in comparing. A single 'equals' is the assignment operator in C, which means that it wouldn't compare the value of a variable with something, it would instead assign that value to the variable. Think about it.

One final note about RTcmix and C-like syntax: all of the C constructions are available in RTcmix (do-loops, while-loops, nested loops, &&, || operators, etc.) with two big exceptions. RTcmix does NOT require semicolons at the end of each statement. The only place where semicolons are needed is in the for-loop setup as noted above. RTcmix also does NOT support unary pre- or post-fix operators, so "++var" and "var--" do not work.

After this brief overview, we explored the PeRColate physical model algorithms, which allow you to dynamically mess around with the phys-model params and hear the results. Fun! Check out the help patches that come with the PeRColate objects.

Then Jason had fun with transcoding. Patches above, plus more to come in FUTURE CLASSES!