Category: Uncategorised

The Science of Sound

I’m not teaching any more, but I don’t want to just bin a decade worth’s of lecture notes, so here’s part of the first lecture tech students get in their first week of university:

To talk about sound, we must first talk about air. This is made up of about 78% nitrogen, 21% oxygen and various other gases. At 20 degrees Celsius (that is, room temperature), each air molecule is moving all the time at 500 metres per second. They are constantly colliding with each other and with anything in their path.

If a football hit you at 500 m/s, you’d be in trouble, but air molecules are tiny. Force = mass* acceleration. The force of a football is huge in comparison to a single nitrogen atom. But if you pump a lot of air into a tyre, say 6 bar (87 psi), the force of all the colliding air molecules will make the tyre very stiff. At sea level, the pressure of the atmosphere is about 1.03 bars (14.7 psi).

So how does sound propagate in air? Let’s say Adam Kryński hits his Bodhrán with a stick.

A man is holding a frame drum and is about to strike it with a beater.
Figure 1: Adam Kryński plays Bodhrán, Lestat (Jan Mehlich), CC BY-SA 2.5 <https://creativecommons.org/licenses/by-sa/2.5>, via Wikimedia Commons

This causes the drum membrane to move very suddenly. He pushes the membrane and, on the other side of the drum, the membrane pushes on all the air molecules. They get packed in together. This creates a band of high pressure, that starts at the drum and moves outwards. All the molecules are moving at 500 m/s. But they’re not all going in the same direction. Some are going away from the drum, but some are going sideways or backwards. They’re all crowded though, and colliding into the molecules around them, so that wave of intense collisions, the high pressure wave, is moving away from the drum at 340 m/s, at room temperature.

If we were in Death Valley when it was 20 degrees out, the air pressure would be higher, so there would be more collisions. However, the air molecules would still be moving at their normal speed, so the pressure wave would still move at 340 m/s. If we were on Mount Everest at 20 degrees, there would be fewer collisions, but the speed would still be the same.

However, at 30 degrees, air moves faster, so sound moves faster. And at 10 degrees, air is slower so sound is slower.

Kryński’s drum head has creates a high pressure wave when it moved from being hit, but it doesn’t stay in that position. The drum head snaps back in the other direction, passing it’s mid point. This movement backwards creates a space where there are fewer air molecules. A low pressure wave follows the high one, moving at the same speed.

The head, still out of place snaps back forwards again, creating another, smaller, pressure wave and then another smaller wave of low pressure.

We can see a simulation of this drum head via Falstad.

Alternating light and dark lines fan out from the top of the image towards the bottom.
Figure 2: A ripple tank simulation of a vibrating plane with a short wall on either side, generated via Falstad

You can see the high and low pressure waves. In this simulation, the drum head vibrates forever, but it does give you an idea of the sound waves moving away from the drum.

These sound waves might reach your ear. But what is the amount of pressure change that your ear is actually perceiving? At sea level, the pressure of the atmosphere is 101.3 kilo pascals. The pressure change created by sound waves is in micro pascals, a tiny amount. It’s possible for air pressure to vary by more than that. A 1% change in pressure travelling at the speed of sound is, essentially, an explosion that can knock over a building. Atmospheric pressure, such as high and low pressure fronts you hear about in the weather forecast, has big variances relative to sound, but these changes happen very slowly.

A map of pressure zones over North America, showing pressure in pascals.
Figure 3: Surface pressure in North America (NOAA) Public Domain Hydrometeorological Prediction Center, Public domain, via Wikimedia Commons

Live-Blogging Dorkbot #2

More #Dorkbot
Kooman Samani

Lovotocs = Love + Robotics

This came out of social robots.
Western dualism includes both body and mind but also emotion and reason. This is falling out of favour towards monoism.

Love is covered by psychology philosophy etc.

Robots: industrial, service, social, and love?

There is a risk of the uncanny valley. Creepiness is also cultural. He decided to go for an abstract design and a simple looking interface.

Most people don’t think they could love a robot but are fine with robots loving them.

This project was fed by robots and AI but also by psychology.

Why do we fall in love? Repeat exposure is a factor.

His AI system emulated an endocrine system.

The state of the robot depends on the previous state, the endocrine emulation and the input.

This is slightly problematic … Like, one of the persistent problems in both AI and robots is that people want to assume emotion from the machine and this is just encouraging that.

Live-Blogging Dorkbot #1

Sarah Angliss wrote an opera. She did composition and sound design. She had to learn to write for other people and make everything reliable.

Fifteen years ago she went to the Hunter Museum in London, including a skeleton of Charles Burn, who did not want his skeleton exhibited. His body was stolen after his death by Hunter. Her opera was about Burn. She spent seven years writing the opera, during which time the Hunter museum responded to pressure and removed the display.

Some of the instruments in the opera are her robots, including a carillon. She also used theremin. But mostly 18th century instruments used in weird ways.

Theatre uses some software called Q Lab.

She’s got a live looping device that does subtle weird stretching. There are several loop points on the phrase.

She got really into 1969s spectralism. Her stuff is based on the nightingale. The problem with mapping an FFT to a violin is that violins also have spectrums. She wrote software to take into account the violin’s spectrum. IRCAM’s software OrkIdea does this well.

Obituary for Edward Hutchins

Edward Hutchins passed away on June 19th at the age of 83 in McKinney, TX, after a short illness.

Ed was born to Esther and Bert in St Louis, MO, in 1939, but the family soon relocated to Phoenix, AZ. After a brief stint at Arizona State, Ed joined the Army and was stationed in Alaska and then San Francisco. After being discharged, he earned a Bachelor and Masters degree in Electrical Engineering from Santa Clara University. In 1974, he married Eileen Forge and they raised two children in Cupertino, CA.

Ed worked as a chip designer at several Silicon Valley companies, including AMI, Chips and Technologies, IDT and SST. After retiring, he travelled the country on a motorcycle for two years with his tour ending in Vancouver, WA, where he became an avid square dancer with partner Elsie Bartling. He moved to Texas during the pandemic to be closer to his son and grandson.

Ed is predeceased by his parents and his wife Eileen. He is survived by his sons Charles and Edward Paul Jr and grandson William.

Funeral services were be held at St Joseph of Cupertino on August 14 at 1pm. Interment was the following day at Gate of Heaven Cemetery at 10am.

Shiva

My dad’s funeral is delayed for a few weeks due to logistics reasons. So, going out of order, I’ll be sitting shiva in London Tuesday and Wednesday of this week. Please email, text or signal for my address. I have very recently moved house.

A friend suggested I also do an online session. I am considering logistics and will post further details if I go ahead with that.

Graphic Notation Teaching Tool

This is designed for students with no experience of improvising. The idea is to start with just having one note and dots. Then dots and flat lines. Then gradually adding more notes.

It’s meant to fir the window width, so you may need to scroll sideways if you’re looking at this page with a sidebar.

Your browser does not support the HTML5 canvas tag. 
<form id="formElem">
  <label for "notes">Notes:</label>
  <input type="text" name="notes" id="notes" value="C, G">
  
  <label for "dots">Dots:</label>
  <input type="checkbox" id="dots" name="dots" value="1" checked>
  
   <label for="lines">Lines:</label>
<select name="lines" id="lines">
  <option value="0">None</option>
  <option value="1">Flat</option>
  <option value="2">Sloped</option>
</select> 
  <label for "circles">Circles:</label>
  <input type="checkbox" id="circles" name="circles" value="1">

  <input type="submit">
</form>
<canvas height="310" id="canvas_images" style="border: 1px solid #d3d3d3;" width="1280">
    Your browser does not support the HTML5 canvas tag.</canvas>

<script>  
  
  function drawCircle(ctx, x, y, radius, fill, stroke, strokeWidth) {
  	ctx.beginPath()
  	ctx.arc(x, y, radius, 0, 2 * Math.PI, false)
  	if (fill) {
    	ctx.fillStyle = fill
    	ctx.fill()
  	}
  	if (stroke) {
    	ctx.lineWidth = strokeWidth
    	ctx.strokeStyle = stroke
    	ctx.stroke()
  	}
	}
	
	function scoreCircle(ctx, x, y, radius, fill) {}
  
  function drawDot(ctx, x,y) {
    var dots = document.getElementById("dots").value;
    
    if (dots ==0) {
      return false;
    }
    drawCircle(ctx, x, y, 5, 'black', 'black', 2);
    return true;
  }
  
  function drawLine(ctx, x1, y1, x2, y2) {
    ctx.strokeStyle = 'black';
    ctx.lineWidth = 5;

    // draw a red line
    ctx.beginPath();
    ctx.moveTo(x1, y1);
    ctx.lineTo(x2, y2);
    ctx.stroke();
  }
  
  
  function scoreLine(ctx, x1, y1, x2, height) {
  
    var lines = document.getElementById("lines").value;
    if( lines == 0) {
      return false;
    }
    
    if( lines == 1) {
    
      drawLine(ctx, x1, y1, x2, y1);
    } else {
  
      var slopes = [-1, 1, 0, 0, 0, 0, 0]
      var diagonal = slopes[Math.floor(Math.random()*slopes.length)]
  
      if (diagonal != 0) {
        x2 = x2 + height;
      }
    
      var y2 = y1 + (height * diagonal);
      drawLine(ctx, x1, y1, x2, y2);
    }
    
    return true;
  }


  function pickItem(ctx, x1, y1, x2, height, radius, fill) {
  
    index = Math.floor(Math.random() * options.length);
    switch (options[index]) {
      case 0:
        drawDot(ctx, x1, y1);
        break;
      case 1:
        scoreLine(ctx, x1, y1, x2, height);
        break;
      case 3:
        scoreCircle(ctx, x, y, radius, fill);
        break;
      }
  }
  
  
  function drawScore(ctx, staves, dots, lines, circles){
    var canvas_width = ctx.canvas.clientWidth;
		var canvas_height = ctx.canvas.clientHeight;
    var height = 0;
    var stave_height = Math.floor(canvas_height / ( staves + 1));
    var num_items;
  
    var range = canvas_width / 20;
    
   
		
		
    for (let i = 0; i < staves; i++) {
  		num_items = Math.floor(Math.random() * 5) + 5;
      height += stave_height;
      //drawDot(ctx, Math.floor(Math.random * canvas_width), height);
      for(let j=0; j < num_items; j++) {
        //  pickItem(ctx, x1, y1, x2, height, radius, fill)
     		//drawDot(ctx, Math.floor(Math.random() * canvas_width), height);
     		var x1 = Math.floor(Math.random() * canvas_width);
     		var x2 = x1 + Math.floor(Math.random() * range) + 20;
     		var radius = Math.floor((Math.random() * (stave_height / 2)) + (stave_height / 2));
     		pickItem(ctx, x1, height, x2, stave_height, radius , Math.floor(Math.random()  * 2));
      }
		} 
  }
  
  function parseForm(ctx) {
     ctx.clearRect(0, 0, ctx.canvas.width, ctx.canvas.height);
     
    var allnotes = document.getElementById("notes").value;
    context.fillText(allnotes, 30, 60);
    var notes = allnotes.split(",");
    
    options = [];
    
    //var dots = document.getElementById("dots").value;
    //console.log(dots);
    if (document.getElementById("dots").checked) {
      options.push(0);
    }
    var lines = document.getElementById("lines").value;
    if( lines != 0) {
      options.push(1);
    }
    
   var circles = document.getElementById("circles").value;
    if( circles != 0) {
      options.push(2);
    }
    
    console.log(options);
    
    if (options.length > 0 ) {
      drawScore(ctx, notes.length, 1, 0, 0, 0);
    }
  }
  

    var c = document.getElementById("canvas_images");
    c.width = 0.99 * window.screen.availWidth; 
    c.height = Math.max(c.height, 0.4 * window.screen.availHeight);
    var context = c.getContext("2d");
    //var numGlyphs = Math.floor((Math.random() * 3) + 1) + 1;
    //var blob = new Image();
    //var x, y;

    context.font = "300% Bravura";
    //blob.src = "https://farm8.staticflickr.com/7322/9736783860_4c2706d4ef_m.jpg"
    //blob.onload = function() {
    //    context.drawImage(blob, 0, 0);
    //    for (var i = 0; i < numGlyphs; i++) {
    //        x = Math.floor((Math.random() * i * 50) + 1) + 5;
    //        y = Math.floor((Math.random() * 205) + 1) + 7;
    //        //1f49b
    //        context.fillText("<3", x, y);
    //    };

    //};
    //context.fillText("<3", 100, 100);
    
    //drawScore(context, 1, 1, 0, 0);
    
    var options = [];
    
    parseForm(context);
    
    formElem.onsubmit = async (e) => {
    	e.preventDefault();
			parseForm(context);
    }

</script>

Laptop and Tuba

This post is taken from the lightening talk I gave at AMRO

Abstract

I have decided to try to solve a problem that I’m sure we’ve all had – it’s very difficult to play a tuba and program a computer at the same time. A tuba can be played one-handed but the form factor makes typing difficult. Of course, it’s also possible to make a tuba into an augmented instrument, but most players can only really cope with two sensors and it’s hard to attach them without changing the acoustics of the instrument.

The solution to this classic conundrum is to unplug the keyboard and ditch the sensors. Use the tuba itself to input code.

Languages

Constructed languages are human languages that were intentionally invented rather than developing via the normal evolutionary processes. One of the most famous constructed languages is Esperanto, but modern Hebrew is also a conlang. One of the early European conlangs is Solresol, invented in 1827 by François Sudre. This is a “whistling language” in that it’s syllables are all musical pitches. They can be expressed as notes, numbers or via solfèdge.

The “universal languages” of the 19th century were invented to allow different people to speak to each other, but previously to that some philosophers also invented languages to try to remove ambiguity from human speech. These attempts were not successful, but in the 20th century, the need to invent unambiguous language re-emerged in computer languages. Programming languages are based off of human languages. This is most commonly English, although many exceptions exist, including Algol which was always multilingual.

Domifare

I decided to build a programming language out of Solresol, as it’s already highly systematised and has an existing vocabulary I can use. This language, Domifare is a live coding language very strongly influenced by ixi lang, which is also written in SuperCollider. Statements are entered by playing tuba into a microphone. These can create and modify objects, all of which are loops.

Creating an object causes the interpreter to start recording immediately. The recording starts to play back as a loop as soon as the recording is complete. Loops can be started, stopped or “shaken”. The loop object contains a list of note onsets, so when it’s shaken, the notes played are re-ordered randomly. A future version may use the onsets to play synthesised drum sounds for percussion loops.

Pitch Detection

Entering code relies on pitch tracking. This is a notoriously error-prone process. Human voices and brass instruments are especially difficult to track because of the overtone content. That is to say, these sounds are extremely rich and have resonances that can confuse pitch trackers. This is especially complicated for the tuba in the low register because the overtones may be significantly louder than the fundamental frequency. This instrument design is useful for human listeners. Our brains can hear the higher frequencies in the sound and use them to identify the fundamental sound even if it’s absent because it’s obscured by another sound. For example, if a loud train partially obscures a cello sound, a listener can still tell what note was played. This also works if the fundamental frequency is lower than humans can physically hear! There are tubists who can play notes below the range of human hearing, but which people perceive through the overtones! This is fantastic for people, but somewhat challenging for most pitch detection algorithms.

I included two pitch detection algorithms, one of which is a time based system I’ve blogged about previously and the other is one built into SuperCollider using a technique called autocorrelation. Much to my surprise, the autocorrelation was the more reliable, although it still makes mistakes the majority of the time.

Other possibilities for pitch detection might include tightly tuned bandpass filters. This is the technique used by David Behrman for his piece On the Other Ocean, and was suggested by my dad (who I’ve recently learned built electronic musical instruments in 1960s or 70s!!) Experimentation is required to see if this would work.

AI

Another possible technique likely to be more reliable is AI. I anticipate this could potentially correctly identify commands more often than not, which would substantially change the experience of performance. Experimentation is needed to see if this would improve the piece or not. Use of this technique would also require pre-training variable names, so a player would have to draw on a set of pre-existing names rather than deciding names on the fly. However, in performance, I’ve had a hard time deciding on variable names on-the-fly anyway and have ended up with random strings.

Learning to play this piece already involves a neural learning process, but a physical one in my brain, as I practice and internalise the methods of the DomifareLoop class. It’s already a good idea for me to pre-decide some variable names and practice them so I have them ready. My current experience of performance is that I’m surprised when a command is recognised and play something weird for the variable name and am caught unawares again when the loop begins immediately recording. I think this experience would be improved for the performer and the listener with more preparation.

Performance Practice

The theme for AMRO, where this piece premiered was “debug”, so I included both pitch detection algorithms and left space to switch between them and adjust parameters instead of launching with the optimal setup. The performance was in Stadtwerkstadt, which is a clubby space and this nuance didn’t seem to come across. It would probably not be compelling for most audiences.

Audience feedback was entirely positive but this is a very friendly crowd, so negative feedback would not be within the community norms. Constructive criticism also may not be offered.

My plan for this piece is to perform it several more times and then record it as part of an album tentatively titled “Laptop and Tuba” which would come out in 2023 on the Other Minds record label. If you would like to book me, please get in touch. I am hoping that there is a recording of the premiere.

Community servers

live blogging AMRO

where have all the servers gone?

Aileen used to run a home LAN which grew into a home server, hosting 60 domains. Domains belong to people. Human relationships are central to all community projects.

Art spaces used to require community ISPs. Some of these have migrated to do hosting for art orgs. Some have migrates to hosting individual artists or collectives.

Some groups use servers as a part of feminist practice, knowledge sharing and collective empowerment. Feminist servers can be intergenerational. They can have joyfulness, reflection, and peer support.

There are still different wants to think about where and how to do servers. Always-on is not necessarily the most important value for arts servers.

Homebew self-hosting is cool again! There are collectives of people doing this.

Servus.at runs a proper data centre. Theyare a membership organisation. They also do operate as service that aims at reliability.

Sharing tech knowledge is a particular skill that not all techies possess.

There are dualities in trying to run an NGO in a capitalist space like the internet. Values about uptime and so forth cause friction. Things break and people get frustrated, so there is serious emotional labour in relationship-based tech services. They are trying to use tools made for profit on a non profit context.

What is the relationship between the server and the community?

User education is important. “The server is a.physical thing. We blew a fuse. Please stand by.”

One group has a mobile raspberry-pi based server. It is currently downstairs. When its on trains, its offline.

ISPs have histories. People working at them encounter users at moments of errors.

Knowledge transmission is always incomplete. Servers are complex and documentation is hard.

Capitalism is an inescapable context. The contradiction this creates is never resolved. Fixing servers can be hard or boring or frustrating.

What if computing was seasonal?

Community server NGOs are chronically underfunded. Membership organisations doing servers make members part owners. This gives a meaningful relationship with the infrastructure and reliability in terms of organisational stability. And data sovereignty.

Self hosting is not safer in terms of data reliability. Back up your data. If the data is necessary for you, then form a plan to preserve it.

How have things changed since serves was founded? People want to form collectives, but its unapid time and effort to document things.

Embrace, extend, extinguish fucks up stable protocols and makes things harder to maintain. Free software companies are also capitalist.

Systems can become hacks upon hacks upon hacks. Even Foss projects can chase shiny overcomplexity. Some building blocks may be politically neutral but systemic tools reflect capitalist values.

Thank your sysadmin!

Systerserver exists for people to learn. They have a system for shared command line sessions so everyone shares a terminal.

A matonaut is now reminiscing about the 90s and that era of websites. In the old days these collectives were about giving access. But now it seems like a lifestyle choice.

arts servers have greater longevity than community servers due to more sustainable funding models. (Oh, to be European!)

Q: Has the war in the Ukraine effected solidarity networks in hosting? What about circumventing blocks? Guides for activists now in effected regions are howto exploit gaps, not how to host. Telegram somehow allows a way to create proxies. This creates dependencies on corporations like Amazon, telegraph etc. How can we regain agency? Can we communalism proxies?

A: Activists in Rotterdam started building up resources. But there’s so much fragmentation. Will USB sticks be a thing? Some activists are still using Facebook because it feels safer than many mastodon servers.

Could mirroring be a useful practice?

What kind of resource sharing would help support community servers? We don’t wish to be islands!

Documentation/ information sharing can be helpful.. Store playbooks in git repos.

the era of websites shoukd be over. Nobody needs websotes any more. We should move on and make text services for text.

its time for an attitude change. Changing philosophy can change terminology can change philosophy can create situated knowledge. We can use this change in mindset to slow down.

Linux community’s are corporatised and isolating.

Q: Ate feminist server communities a service?

A: partially. Artists are relying on etherpad and some other services. There is a syster server mastodon instance.

Farmasoft quit serving schools during the pandemic because they did not have the resources to sustain that useage level. This had implications for teachers who were trying to avoid google docs. But also, it was an emergency and they didn’t have the resource. When should money get involved in these processes?