Extending the Mapping for the Muon Detector

I woke up at 3AM and decided to extend the mapping used for the sonification of Robert Hart's 3GM homemade muon detector. You can read what I have done previously in terms of mapping here. The way in which I have extended the mapping is relatively opaque and distanced from the actual data - this is because mapping sonic data from what is essentially a one bit stream in a meaningful feels a little like squeezing blood from a stone.

You can listen to an outcome here. This does not represent the final state of a mapping with which I am happy, but it is some sort of start. I hope.

However, I would consider this a challenge and a way to overcome limitations rather than a negative aspect. So, as a result, the mapping is a little more abstract and indirect now compared to my previous example.

The mapping and subsequent audio output has been extended in a number of ways. Instead of triggering just one sample, the mapping triggers a total of 11 samples - 3 of which are triggered 'directly' from the incoming data, and 8 of which form part of a drum machine.

The three 'directly' triggered samples have their velocity controlled by the accumulator system (as described in my previous blog entry on this subject). One of the samples has the pitch also set by the accumulator.

With the more indirect samples (the drum machine), the data that controls them is generated in a more complex fashion. In a sense, the first part of this generation / interpolation aspect is similar to the accumulator setup.

Keep in mind that the muon detector can detect one ray at one given point in time, for only one position. What this means in terms of the data output is that if a ray is detected, then a high state (a 'one', basically) is sent to the computer.

What the computer does, in order to generate the drum machine data, is to poll the output of the muon detector once every 350 milliseconds (this can be changed based on the environment and how 'busy' the outcome should be). If in this polling period, the computer has detected a cosmic ray, then a high state is stored. If in this polling period, the computer has not detected a cosmic ray, then a low state is stored.

This series of 1's and 0's corresponding to each polling period is placed in a 32-bit buffer (which is, as a result of continuous detection polling, being updated constantly). This buffer of 32 bits in length actually forms the basis for the two high bytes and the two low bytes used in my bitwise rhythm generator (which can be read about here and here).

Basically, this bitwise rhythm generator uses these two words (so, two high bytes and two low bytes or 32-bits worth of information) and a set of user-determined logic gate operations to form a looping rhythmic sequence of one to four bars in length (depending on the user settings). The data from the bitwise rhythm generator is sent to Ableton Live as MIDI data - in a format suitable for the Impulse device.

This bitwise rhythm generator also includes provision for combining the data inside of the sequencer to generate MIDI CC messages (to be precise, message streams). The idea is to be able to use just four bytes of data to generate (relatively) complex rhythms as well as control data.

This MIDI CC data is then also sent to Ableton Live, where it controls various effects and instrument paramters associated with the previously mentioned Impulse device. Approximately forty parameters are controlled from just three MIDI CC streams, from reverb depth, delay times, frequency cut offs and compression thresholds, to transposition, time compression / expansion, bit crushing and saturation character. See the full list in the screen shots below.

MIDI Mapping, Page 1

MIDI Mapping, Page 2

Bitwise Rhythm Generator

The current muon detector Max/MSP patch

Cosmic Radiation Detection Sample Triggering

I've been working on making music using the muon detector setup about which I have written previously. The feature that has been added is a simple accumulator. In essence, it outputs a MIDI CC value, which increases if there are many hits in a short period of time, but decreases if there are little or no hits. It is somewhat challenging to think about how a single, one bit data stream of control information can be mapped to a musical process. Consider this mapping a work in progress.

Muon Detector Live at the Planeterium on October 24!

The muon detector built by Robert Hart will be featured in an upcoming concert organised by Darren Curtis and Pitt Bradlet of Sacred Resonance. The detector will be used in conjunction with audio mappings that I have developed, such as real-time sample triggering and synthesis. The event will take place at the Adelaide Planetarium on October 24th. Details are as follows.



NADAUM EXPERIMENT

2 Sessions at 7pm and 8:30pm. Presented at the Adelaide Planetarium for 1 hour

NADAUM - [Universal Sound Current]

Nadaum is the experience of the universal sound-
scape. It is an activation and experiment merging
images and sound from Cosmic Rays, to Solar Wind.

Allowing the creative soundscape to emerge
in a live music performance, incorporating
the resonance of background sounds of crystal bowls.
The merging of the ancient and modern composition
of Yantra to Mantra.

Sacred Resonance (Darren and Bradley) Live Music-Visuals

Crystal Bowls (Allen Stevens)
‘Cosmic Muon Detector [ by Robert Hart ]
(Cotrolled by Seb Tomczak)

$20 & Conc $15
(Group 3+)
Bookings a must

http://www.sacredresonance.com.au

Homemade Muon Detector, Arduino and Max/MSP

I am fortunate enough to be borrowing a homemade muon detector from my friend Robert Hart of Hardhack.org.au, co-founder of Adelaide Dorkbot and all-round electronics and mechatronics guru.

You can find out more about the particular version of the muon detector that I have been experimenting with here: http://hardhack.org.au/geiger_muller_detector.

The basic concept is to use coincidence detection to filter out terrestrial radiation and leave only data that indicates cosmic radiation.

Today I got around to hooking the device up to my computer via an Arduino board. The model that I am borrowing has three Geiger-Müller tubes, and as such there are two main signals that I would be interested in, namely a coincidence detection for the top and middle tubes, and a coincidence detection for the middle and bottom tubes.

In terms of reading this data via the Arduino, it is actually quite a simple affair. I have connected the three coincidence outputs (top && middle, middle && bottom and ((top && middle) || (middle && bottom))) to Arduino pins 8, 9 and 10. These pins are equavalent to PORTB bits 0, 1 and 2.

Since the output from the detector is a 5V logic signal with a positive signal indicated a coincidence detection, it is then simply a matter of reading the output from PORTB via the PINB command, comparing this reading to the previously-sampled reading, and if the newer reading is different, then printing it via the serial port to the main computer.

The Arduino code is as follows:

byte previous;
byte data;

void setup() {
Serial.begin(57600);
DDRB = B00000000;
PORTB = B11111111;
}

void loop() {
if(PINB != previous) {
previous = PINB;
Serial.print(previous, BYTE);
}
}

It is then simply a matter of using software such as Max/MSP to read the byte and react accordingly. The simplest Max/MSP patch that will decipher the signals into bang triggers is this:

To explain the patch briefly, the metro 3 object is consistently querying the serial a 57600 object whether new data is in the serial input buffer. If there is, the serial a 57600 sends the incoming byte out of its left outlet.

Since the interest lies in bits 0 and 2 (the top && middle and middle && bottom signals), those bits need to be isolated. By first shifting the byte an appropriate amount, and then taking the modulo 2, the specific bits can be easily isolated and dealt with.

The change objects prevent false triggers. The sel 1 objects simply make it so that every transition in the logical signal from a 0 to a 1 will trigger a bang.