Magic Pixie

Years ago I made a little program for Max/MSP as part of my undergraduate degree that uses an image as a score and "plays" it pixel by pixel and feeds the data into a synthesis engine. It was fun to make and use, and I played it at the end of year performance that year. The patch was worth it because as a result a got a permanent exhibition at the (now deceased) Science and Technology Investigator Centre as well as a workshop presentation in Michael Yuen's Project 2 sonic art event.

Today I have revisited this idea with a "new" version of the patch. The images above are "Mandala 10" and "Mandala 11" by the 8bitcollective.com user Campbell. These images were used as data sources in two of my 30 Songs in 30 Days.

This version of Magic Pixie reads a picture in blocks of 4 x 4 pixels, starting in the top left hand corner of the image and working down and right in collumns. Each pixel is stripped down to its RGB components. These values are scaled and fed to Live as MIDI data. Each of the four collumns that are read at a given point in time represents a voice that has a Sega Master System sample loaded into an instance of the Simpler sampling plugin.

Below is the list of MIDI mappings in Live. Naturally, the data could have been used to control an actual Sega Master System, but I do not have one with me today unfortunately.

Formatting Intel HEX Files from a Spreadsheet

I have a need to convert data from a spreadsheet into an Intel HEX file. Although it may seem a little impractical, I decided to use one record entry per data byte, because this made it a little easier (and also, I don't need the hex file itself to be small and efficient - I just need it to work). It has space for 32KB worth of actual data in the hex file.

Here you can see a snapshot of my spreadsheet (from OpenOffice):
Column A is the address as a decimal (from 0 to 32767).

Column B contains my data as a decimal (with the range 0 to 255).

Column C is the colon which marks the beginning of each record entry in a hex file. This is where the formatting for the hex file begins.

Column D is the length field for each entry, which in this case is always set to $01.

Column E is the address as a four digit hexadecimal number ($0000 to $ffff). This is referenced from Column A using DEC2HEX(An; 4), where n is the current row number.

Column F is the record type field for each entry, which in this case is always set to $00 (this indicates a data record).

Column G is the data field as a two digital hexadecimal number ($00 to $ff). This is referenced from Column B using DEC2HEX(Bn; 2), where n is the current row number.

Column H is the checksum as a two digital hexadecimal number. This is calculated as:
=DEC2HEX(MOD((255-MOD((1 + HEX2DEC(En) + HEX2DEC(Gn));256) + 1);256);2), where n is the current row number.

Then it is just a matter of copying and pasting the cell range C4:H32771 into a text file, adding the END FILE entry (cell range C2:G2 or simply :00000001FF) and replacing all spaces with nothing.

Pokey: nested 'for' statements

An Atari Pokey sound chip is controlled directly via bus and data lines from an Arduino using three nested 'FOR' statements.

The results are much more complex (and musically interesting) than the code would lead one to believe - a minimalist / maximalist approach.

URL: http://youtube.com/watch?v=aRCPOhP-V7M

Protocol 0.01a

I have been working on ways of getting more data into the Vectrex by extending how data is mapped from the computer to the buttons and thus to RAM location $C807.

The main structure of this protocol is as follows:

• Single 8 bit byte
• Bits 2 - 7 form the data part of the byte
• This holds the range of data that should be mapped to some parameter as shown in the command part of the byte
  
• Bits 0 - 1 form the command part of the byte
• This indicates which parameter the data part of the byte should control
• The range of data and types of parameters are listed in the table below
  

This method of data transfer is a little more dangerous than my previous attempts in that more can go wrong in the transmission. However, the rewards far outshine the negative aspects at this point.

• Monophonic ie. only one note can be played at a time (unchanged)
• Choice of 16 steps of volume (unchanged)
• Choice of 1024 different pitches (up from 16 previously)
• Choice of noise or tone (no choice previously)
• Choice of 32 different noise-shaping steps (up from 16 previously)
  

Of course, this protocol requires a different Max/MSP patch in order to convert generic contrl information into the custom protocol 0.01a. This can be seen below.



Below, you can see a video of the protocol 0.01a in use.