What

I will explain how Bendik Hovik Kjeldsberg and I made an interactive sound installation.

Why

We were invited to make a sound installation.

How

I will go trough the process and discuss some issues we encountered.

——–

About the exhibition:

Bendik Hovik Kjeldsberg and I were invited by Bilder Nordic School of Photography to contribute to an exhibition they called Shameless:

«An exhibition by the graduating students  of Bilder Nordic School of Photography:

SHAMLESS IS A REFLECTION ON SEXUALITY

Sexuality is vital for our survival as a species and gives meaning to our lives. The simple function of reproduction is challenged by the complexity of our heart and brain.

Shameless explores contemporary issues of identity in our society, and the notion of feeling ashamed. Self-image, fantasies, puberty, HIV, minority groups and children’s understanding of sexuality are some of the themes we look into.»

from: bildernordic.no

The exhibition had over 5000 visitors and ran over a period of 10 days.

Placement:

They wanted sound to appear three places in the exhibition hall, all should be short sounds triggered by movement. These places and movements were:

1. When someone went into a room.
2. When someone laid down in a bed.
3. When someone went to the toilet.

Sensors:

Wanting to keep things as simple as possible, we figured out that the sensors that would work for all three scenarios where contact microphones. Contact mics are cheap and robust and works well when you just need an on/off signal.

We soldered xlr plugs to some piezo elements and we were ready to go.

For a more sensitive installation, for example if we wanted to measure how fast some one went into the next room or how heavy the person laying in the bed was, we would have to use other kinds of sensors such as cameras and pressure sensors.

Speakers:

We used three pairs of small handheld speakers and pulled many meters of mini-jack extensions all over the exhibition, I was worried there would be some signal-loss because of the cable length and on the speakers furthest away and we had some problems getting the volume high enough, but still it served it’s purpose.

Sounds:

The thought behind the sounds didn’t emerge from a profound reflection over the theme “shameless”, it was rather a simple and naive way to make the audience feel embraced and some how present an aspect of sexuality in music.

To find the sounds we needed we browsed an open source sound library, freesound.org, we also browsed some porn sites, but we found that quite embarrassing and couldn’t keep it serious.

We chose to have two alternating sounds per area:

System:

I made a standalone application in Max/MSP that ran on an iMac and we used an Avid Mbox Pro sound card for in- and output.

I had to define a limit for how frequent the sensors were active, if not, they would have triggered sounds all the time when there were many people in the exhibition hall. In the application you can define this your self in the number box called “antall sekunder å vente”.

As you can see, the program is divided into four sections. The two faders to the left in each section decide the volume of left and right of the first sample, the two faders at the right decide the volume of the second sample, the fader in the middle decides the threshold for the volume needed from the contact microphone to trigger the sample. The “replace”-button lets you load new samples.

The little square in the middle turns everything on and the “open”-button shows you audio preferences.

Downloads:

Standalone (MAC)

Source Code (Max/MSP)

As those of you familiar with Max/MSP might see, it was made in a hurry.

As I had to make the application in the exhibition hall with a limited amount of time, it ended up quite unsymmetrical and with a language mixture of English and Norwegian, this however reminded me that the patches doesn’t have to look good to work as a one-task-tool that only I have to look at. In this scenario it is more important to get it up and running and focusing on the overall experience of the installation rather than on the layout of the program running it.

Stability:

The system ran flawlessly for 10 days in a row without being turned off (except from when a girl turned off the sound card since it “was so warm”), so it is extremely stable, I was at least expecting to have to go down there once to fix it, but it just worked.

Reactions:

On the day of the opening, the exhibition hall was packed with people and the sounds on the bed and when passing into the other room didn’t quite come to it’s right because of all the chattering and frequent triggering of the sounds. But the setup in the toilet was rather successful since there were constantly people going there and they shared their experiences with the people standing in line when they leaved the toilet, so people started talking about the embarrassing experience of going to the toilet. Due to the nature of the triggered sounds (as sown above), to the presence of a dildo and challenging pictures in the bathroom and to the volume level on the speakers placed there, I must say it made quite an impression having to take a pee in those circumstances.

Timelaps:

Thanks to Anders Tveit for lending us some piezo elements.

The post Making an interactive sound installation appeared first on Drums and electronics.

What:

I will see if I can use a Phidgets-kit on a dancer, it is NOT wireless.

Why:

I am waiting for the Eowave-system to arrive from France and I want some progression in the project.

How:

I will go trough available sensors and think of possible solutions.

——–

Sensors:

These are the available sensors and my thoughts on using them:

Circular Touch:

Too Big.

IR reflective (5mm):

Measures too short distance (max 5mm).

IR reflective (10cm):

Measures too short distance (max 10cm).

Force sensor:

This is both small and sensitive enough to work with.

Magnetic sensor:

Not favorable since the dancer would have to wear a magnet and the distance to where it starts to sense is too short.

Rotation sensor:

I don’t want the dancer to turn knobs, I want her to dance. I could have made something with some strings and springs connected to the knob, but that seems extremely stupid to me.

Touch sensor:

Initially a relevant sensor, but as I tried to put it on a glove, it sensed being on the glove as being touched. I even tried with rubber gloves, still it told me it was getting touched just by sitting on the glove. So I can’t use it.

Motion sensor:

Initially I thought I would be able to use this, but apparently it just senses when there is movement, not on what axis there is movement and how much tilt. That is probably why it is called a motion sensor. Then again, I could use it, but it would not be very clear what it is doing since the numbers I get are quite messy, I would have to try to filter them somehow.

Slider:

Once again, I don’t want the dancer to turn knobs or slides, I want her to dance.

Joystick:

Basically a good idea, but too big for this project.

Temprature sensor:

Cool, but it would be hard to control the temperature instantly based on immediate reactions to what happens in the music.

——–

Wearing the system:

That leaves me with only the force sensor:

I imagined it would be best if the dancer could press it with her fingers, so I put two of them on each their glove:

The dancer would have to wear the interface as well, so I put it on an old belt:

And of course I had to try it on:

Summary:

It felt quite comfortable wearing it, let us just hope that the dancer feels the same way.

Since this system is not wireless, there is a major challenge to actually dance with it, but since I am no dancer, I didn’t bother even trying to figure out how that would work.

As mentioned, this is just a temporary solution until I get the wireless system from Eowave, then I will put together a more permanent solution.

The most important aspect I want to research with this solution is how I will map the incoming data to the processing of the audio. This setup facilitates the concept of starting and stopping a loop as mentioned in the idea sketch:

The two flexion sensors are to decide when to start and stop the looping and also the initial length of the loop. When the left hand closes (if the dancer is close to the drums) is sets the starting point for the loop/starts recording into the looper, when the right hand is closed the en point is set and the loop starts playing. When both hands are opened again the loop stops.

I am thinking that after starting a loop, if more pressure is put on the sensor, that decides the speed and pitch of the loop.

I will also look for a gyroscope to go with this solution so I can use the rotation of the dancers hand(s) to control parameters like we did with the Eowave-system.

The post Testing sensor system on a dancer – temporary solution appeared first on Drums and electronics.

I will test Eowave’s Eobody2 HF on a dancer.

Why:

I want to see if this system works with our project.

How:

I will have the sensors control simple parameters.

——–

After the first day we met I made some enhancements to the setup.

If anyone is interested, this is the current MaxMSP-patch.

I consider pitch, speed and volume as three essential parameters to investigate further as those are quite relevant parameters in traditional music.

In the first example, by turning her hand around the z-axis, the dancer would control the pitch and speed of a simple drum loop.

The reason why we chose not to separate pitch and speed was that after some intents with just controlling the speed we felt that excluding pitch was very unnatural, probably because they both reinforce each others effect and historically we are used to them being tied together (slow down a tape or a vinyl and the pitch will drop).

The original idea was that I would measure the distance between her hands to provoke this action, but we figured out that it would be easier to “fake” it by turning her hands while pulling them apart. I got this idea after an inspiring session with Alexander Refsum Jensenius who made it clear to me that to actually measure the distance between her hands was harder than I initially thought.

As you can see, we are starting to enjoy this. And the system is behaving exactly as expected.

Next, I made turning around the x-axis control the volume of the drum loop.

It is quite obvious that the dancer found this somehow more boring, but it had to be tested and I think we can get a use for it because the link between the movement and the music is so clear.

And again, the system is behaving exactly as expected.

In the next test, I combined the two above, so turning around the z-axis will change the speed and pitch and turning around the x-axis will change the volume of the drum loop.

This clip is notably longer since the dancer is now inspired to explore the possibilities further and we felt that we were ready do to a test performance.

I wanted to emulate that I was playing the drums since that is where we are going, so instead of the drum loop we used a loop from a solo performance I did almost a year ago.

I also wanted to challenge the dancer with some other parameters. This time she controls delay feedback and pitch. You can see the parameters in Ableton Live being modulated in the upper left corner.

I like this. Of course it gets boring after a while, but I would gladly make this a part of a performance.

If I were to play instead of the loop there would be an extremely direct interaction between the music and the dance: I would be playing with both what I hear and see the dancer do and she would be inspired by what I play and what she hear she is doing with the music.

I have now applied for some funding to buy the sensor system and develop a performance with this setup.

Even though this seem quite poor from an artistic point of view, I feel that we are on the right way to do something quite original and the possibilities of what this can bring are just starting to show.

More on this project when money comes around.

The post Testing sensor system on a dancer – day 2 appeared first on Drums and electronics.

I will test Eowave’s Eobody2 HF on a dancer.

Why:

I want to see if this system works with our project.

How:

I will have the sensors control simple parameters.

——–

The dancer:

I was lucky enough to make Hedvig Sønstebø Bang, professional dancer and long time friend, interested in joining the project.

Bang has a BA in jazz dance at The National Academy of the arts (Oslo, Norway) and is currently working as a freelance dancer.

I am utterly grateful for her participation and enthusiasm for the project.

Sensors:

We taped the following sensors to the dancer to control and modulate a simple drum loop:

• Flexion

When she closes her hand she can control the loop.

• Gyroscope

One axis controlling the speed and another the reverb.

Transmitter:

Both sensors are connected to a wireless transmitter attached to the dancer.

——–

First tests:

The fact that nothing sounds like it should and the dancer says that she is getting shocked explains most of the outcome of the first test quite well, but that is how a first test should be, right?

Now the sound is more stable and we got the dancer a glove so that she won’t get shocked. Apparently the flexion sensors that Eowave deliver electrify you if you have the conducting side on your skin, it operates at extremely low voltages so it won’t harm you, but it seemed unpleasant.

Now we tried something more relevant to the project, she looped me saying “blablabla” and then she modulated it.

I think I am starting to see the link between music and dance I have been looking for. As you see at 1:16 the dancer is associating the sounds she is creating with her body.

We felt that the range on the speed is too large: the fastest it way too fast and the slowest might be too slow. Also, the mapping seem to be wrong: both axises are controlling the speed.

——–

Sensor placement:

We wanted to experiment further with the sensor system so we decided to place the gyroscope on other parts of the body. We had no specific method, we just wanted to see if we suddenly would stumble upon something.

In later tests it will be reasonable with a more specific method, but since this was our first encounter with the sensor system, we decided to do it like this.

Now there is no sound in the videos, just an image showing what values we get from the sensors, this might be a little to technical for some, but try to think of it like this:

• All the faders you see jumping up and down I can make control any parameter of the music.
• The faders are jumping up and down because of the movements of the dancer, try to see the link.
• If you try to imagine the faders controlling for example reverb, speed and volume you might understand why we are doing these tests.

Stomach:

We get quite clear readings here, this could definitely be used for something. But as Hedvig made me aware of, dancers doesn’t normally dance just like that, so we did a test with some more movements with the gyroscope still on the stomach.

I should probably have put on some music and let her dance, because this seemed somehow too forced.

But the fact that the faders start moving seemingly randomly when she starts dancing could be an interesting aspect. Maybe that way we will stumble upon ways to modulate sound that would never have been done if it was not a part of a dance.

Knee:

It would be cool to “kick” sound, and this way it is certainly possible.

Apart from that I don’t see any immediate use for a sensor at the knee. Suggestions are more than welcome.

Foot:

A sensor placed at the foot also enables the emulation of kicking a sound. Also it seemed more flexible to have it here than at the knee. Maybe a “straight” foot could enable another set of effects than a “flat” foot. For example a “straight” foot would make the stomach sensor control reverb whilst a “flat” foot would make it control a filter?

The post Testing sensor system on a dancer – day 1 appeared first on Drums and electronics.

I will determine what sensor system to use.

I have to find the most practical and effective solution for collaboration with a dancer.

Why:

I want to be sure I am using the most convenient system before i involve the dancer.

How:

I will discuss the subject with Alexander Refsum Jensenius.

Alexander Refsum Jensenius (BA, MA, MSc, PhD) is a music technology researcher living in Oslo, Norway

www.arj.no

——–

Sensor system:

Jensenius and I discussed the selection of sensor systems and I will narrow it down to this solution based on the following criteria:

• It has to be wireless.

Dancing with a cable going to the computer would be very inconvenient.

• It cannot be based on Bluetooth.

Jensenius explained to me that he has had bad experiences with Bluetooth based systems. They could be stable for a while, but suddenly on some occasions it wouldn’t work. His theory was that many in the audience might have a cellphone with Bluetooth enabled and that could interfere with the system. Also that the structure of some venues simply wouldn’t allow Bluetooth to operate.

• It cannot be based on WiFi.

Most WiFi solutions demand a lot of power which would mean we would have to recharge the system very often. I considered an Arduino system with an Xbee shield and from these battery tests, it seemed quite good. But I have just barely tried to program an arduino and it would demand too much of my time.

• It has to be flexible.

Since I do not yet know what movements I want to register with what sensors, the system i choose has to be flexible in these aspects.

• It has to be affordable.

I am a student.

The available sensor system which met all these criteria was the Eowave Eobody2 HF (how affordable it is can still be discussed).

Time consumption vs productivity:

The fact that that I am skilled enough to get this system up and running quickly is an important aspect.

As my main focus on my masters degree is to create music, using a lot of time programming a setup would be considered time consumption. This has been one of my main challenges this year, to balance the amount of time used on technology and the amount of time for creating music.

The best way to do this would be to get a system, as simple as it might be, up and running as fast as possible and rather develop it further parallel with the creation of the music and choreography. Then I will know what the system is lacking since I know exactly what I expect it to do. Yet this is a hard situation since I do not know exactly what the system should do before I start creating the music and I do not know exactly what musical possibilities I have before the system is up and running.

It is important that these statements are subjective, you might not consider programming time consumption. Here are some slightly different thoughts on productivity vs. time consumption seen trough the eyes of blogger and programmer Trevor Pascal:

The post Choosing the right sensor system for a dancer appeared first on Drums and electronics.

(…) a sensor based setup for a dancer and a drummer, where the dancer can pick up sounds played by the drummer and process them with movement (…)

My project description

What:

Dancer wearing sensors – controlling sound.

The idea is that the dancer can approach my drum set (sound source) and pick up the sounds I am making at that instant. Then he or she can modulate the sounds with movements and try to make it artistically interesting and fitting to the rest of the music if there is any.

Why:

Concrete interaction between music and dance.

The main motivation behind this is that I want to experience a more concrete interaction between a dancers movements and a musician sounds in a live performance setting.

How:

I will make a patch in Max/MSP, buy sensors and rehears with a dancer.

Equipment and procedure:

The dancer will have to wear some kind of gloves and maybe some socks/shoes with the following sensors:

Gyroscope:

A gyroscope is a device for measuring or maintaining orientation, based on the principles of angular momentum. Thanks to the fast development in smartphone technology they are now extremely small and quite cheap and can look for example like this (not the coin):

In this context the gyroscope will be used mainly for detecting the rotation of the dancers feet and hands.

More on gyroscope sensors here.

Flexion (bend):

Flexion sensors, (from Latin flectere, ‘to bend’) also called bend sensors, measure the amount of deflection caused by bending the sensor. There are various ways of sensing deflection, from strain-gauges¹⁾ to hall-effect sensors²⁾. The three most common types of flexion sensors are:

• conductive ink-based
• fibre-optic
• conductive fabric/thread/polymer-based

www.sensorwiki.org

The flexion sensors will be used to detect when the dancer is closing or opening his or her hands.

More on flexion sensors here.

Distance (Infrared):

These sensors uses infrared light whose waves are those just below the visible spectrum of frequencies. I will use one of these to determine the distance between the dancers hands.

More on infrared sensors here.

Radio-frequency identification:

Radio-frequency identification (RFID) is a technology that uses radio waves to transfer data from an electronic tag, called RFID tag or label, attached to an object, through a reader for the purpose of identifying and tracking the object.

I will place a RFID tag on the dancer and RFID readers by the drums and in the buckets (see explanation further down) or the other way around so that when he or she gets close to the buckets or drums it gets registered.

RFID tags can look like this:

RFID readers can look like this:

More on RFID sensors here.

Movement tracking:

I would also like to track the dancers movement on stage, for example with a Kinect so that the sounds that are being carried can be panned to the corresponding location on stage.

Buckets:

The idea also includes some buckets with RFID sensors where the dancer can place the sounds so that they stay looped while he or she continues the performance. It would also be convenient with some lights in the buckets representing if they contain a loop or not.

…

Mapping:

Once again the most challenging factor is the mapping, mapping is to choose what the sensors/controllers should do. A crucial point for me is that the sensors functions are obvious.

I am not quite sure of the gyroscopes function yet, but I guess it will be a filter, delay, distortion or a reverb or a combination of all of them. I could of course say that the dancers placement on stage or another parameter should decide what effect to use, but I will try to keep my feet at the ground and restrict my self until further on in the process so that it will be easier to start working on it.

The two flexion sensors are to decide when to start and stop the looping and also the initial length of the loop. When the left hand closes (if the dancer is close to the drums) is sets the starting point for the loop/starts recording into the looper, when the right hand is closed the en point is set and the loop starts playing. When both hands are opened again the loop stops.

The distance sensor in one of the hands sees the distance to the other hand and, if a loop is playing, decides the speed and pitch (not sure about pitch yet) of the loop. When the hands are closer, the loop plays faster and when the hands are further apart, the loop plays slower.

The RFID sensors, as already mentioned, are to decide if the dancer can record new sounds or not and to tell when a sound is supposed to keep on looping “in a bucket”. If the closed hand is in a bucket wile it is released, it keeps on looping and the dancer can go make another loop.

So the left hand has:

• Flexion.
• Gyroscope.
• RFID.

The right hand has:

• Flexion.
• Gyroscope.
• Distance.

For now, the feet will just have each their gyroscope.

Hypothesis:

I think the first rehearsal will just be amusement over the feeling to “touch sound” and over-using it – like when a guitarist gets a new pedal. Further down the road we will probably encounter problems if we want to play in time and we want loops to be in sync, then I will have to create some kind of transport control and we will need a metronome or backing track.

I think the main challenge will be for the dancer to merge the performance of music and dance. I might have to compose something that he or she can dance, maybe not down to the finest detail, but I think it will be a challenge to improvise well with this setup, then again, hopefully I am wrong.

Reflection:

We will obviously have to practice a lot to make the end result a good experience. I feel that the concept is not strong enough to stand by it self for more than the first 5 minutes of amusement over the technology. I might realize that this is just a dead end, but I have a strong feeling it will not result in that because of earlier experiences with the common denominator between music and dance (see the “Dancers-section of this blog).

Special thanks to Haakon Berg Mathisen for thoughts on how to write well for the internet.

The post Dancer controlling sound with sensors – Idea sketch appeared first on Drums and electronics.

(…) I should instead dive into my setup, experiment and play with it and get to know it as well as possible.

I stumbled upon an interesting aspect where a certain combination of effects resulted in a controllable feedback as shown below:

I used a tone generator, a delay that sounds “drrr”, a simple delay, a reverb (Lexicon Chamber) and another reverb (Waves’ IR1) in that specific order.

The track looking like this:

At the master bus I had a reverb, an auto filter and a limiter like this:

The most essential factor however, is the placement of the microphones and speakers and their properties. I used my “ukko -b-band” microphones in the tom but the other microphones might also have contributed to the feedback to a certain extent.

Anyways, the most interesting aspect with this, I think, is that while improvising with my setup I can stumble upon something unexpected even though I thought I knew every millimeter of my setup. I try to always allow this to happen when performing live. Sometimes it sounds really bad, but other times it’s exactly what the piece needed. That is of course an essential factor of improvising; to be open for other outcomes than you originally expected.

Then again, some artists do not approve of incorporating random factors to their performances. Or at least not a random “decided” by a computer. For me this has been a dilemma for a while, but I think it is all about moderation, that the computer random can be included to a certain extent. Personally I like to have control over what I do, however, the computer random can give me ideas that I can shape as I like or throw away if I do not like them.

The post Random impulses appeared first on Drums and electronics.

One of the first issues I wanted to look into when I started working on my master thesis was audio latency.

Audio latency is the delay between when an audio signal enters and when it emerges from a system. Potential contributors to latency in an audio system include analog-to-digital conversion, buffering, digital signal processing, transmission time, digital-to-analog conversion and the speed of sound in air.

The reason I wanted to look into this immediately is that I felt that for a drummer, being quite conscious about timing, this would be an essential aspect.

To elaborate further:

When playing with effects such as reverbs and other effects that lasts for a certain amount of time, I don’t feel that some milliseconds back or forth have any disadvantage, it could actually be an interesting musical aspect.

But when it comes to triggering sounds, delays, looping, gating and other effects that have to react fast, audio latency is relevant.

When I started testing this, I was very fixated on finding the sound card with the lowest latency and I thought that when I did, it would radically revolutionize my setup.

With my current setup, I have to live with a total latency at about 8 milliseconds. What i gathered from my research (as shown below) is that I could obtain a latency at about 2 milliseconds with a certain, and quite affordable setup. That’s a difference of 6 milliseconds, let’s put that into context.

In dry air at 20 °C, the speed of sound is 343.2 meters per second. That is 343.2/1000 = 0.3432 meters per millisecond ≈ one meter in 3 milliseconds. So the difference in audio latency between the two sound cards corresponds to two meters in distance to a sound source. Many guitarists have at least that distance to their amplifier. The distance from my drums to my ears could be close to a meter, that’s 3 milliseconds. What about a taller drummer than me, that would mean even more latency. From this reflections, I can’t conclude on anything else than that it’s all about habituation.

So, to a certain extent one can get used to a fair amount of latency, you learn to press “loop” a little bit before you actually will loop, and you make sure you push the beat just a little bit when playing with delays or triggering samples. This definitely doesn’t have to be conscious, by practicing and listening, one adapts to this quite quickly.

But compressors, gates and similar effects still demand low latency to operate at their best. When compressing drums, I don’t think you would want to add another 8 milliseconds before the compressor actually kicks inn. That’s why I completed the following test.

First, a brief run trough of the parameters needed to control the latency.

– Sampling rate:

When analog audio is sent into the computer, it goes into an ADC (Analog-to-digital converter) which takes X samples of the audio per second. X is defined in hertz, is called the sampling rate and is usually at a value of 44’100 or above if you want to listen to Swedish-American engineer Harry Nyquist and how his theorem is described on Wikipedia:

In theory, a Nyquist frequency just larger than the signal bandwidth is sufficient to allow perfect reconstruction of the signal from the samples: see Sampling theorem: Critical frequency. However, this reconstruction requires an ideal filter that passes some frequencies unchanged while suppressing all others completely (commonly called a brick-wall filter). In practice, perfect reconstruction is unattainable. Some amount of aliasing is unavoidable.

Signal frequencies higher than the Nyquist frequency will encounter a “folding” about the Nyquist frequency, back into lower frequencies. For example, if the sample rate is 20 kHz, the Nyquist frequency is 10 kHz, and an 11 kHz signal will fold, or alias, to 9 kHz. However, a 9 kHz signal can also fold up to 11 kHz in that case if the reconstruction filter is not adequate. Both types of aliasing can be important.

When attainable filters are used, some degree of oversampling is necessary to accommodate the practical constraints on anti-aliasing filters: instead of a brickwall, one has flat response in the passband up to a point called the cutoff frequency or corner frequency, (pass all frequencies below there unchanged), then gradual rolloff in a transition band, finally suppressing signals above a certain point completely or almost completely in the stopband. Thus, frequencies close to the Nyquist frequency may be distorted in the sampling and reconstruction process, so the bandwidth should be kept below the Nyquist frequency by some margin (frequency headroom) that depends on the actual filters used.

For example, audio CDs have a sampling frequency of 44100 Hz. The Nyquist frequency is therefore 22050 Hz, which is an upper bound on the highest frequency the data can unambiguously represent. If the chosen anti-aliasing filter (a low-pass filter in this case) has a transition band of 2000 Hz, then the cut-off frequency should be no higher than 20050 Hz to yield a signal with negligible power at frequencies of 22050 Hz and greater.

– Buffer size:

A buffer in this contexts can be explained as how much time the computer can use for “processing” before we have to see or hear something happening and it is defined in samples. So, if the buffer size is 512 samples and the sampling rate is 44’100Hz, the buffer adds an additional delay of 512/44100 ≈ 0.012 = 12 milliseconds. The computer do need a buffer, how low you can go regarding buffer size depends on the computers cpu, ram and hdd speed but also, a really important factor is what audio interface (sound card) you are using. This is because all the manufacturers write their own drivers and have different ADC’s (analog-to-digital-converters) and DAC’s (digital-to-analog-converters), which are all major contributors to latency.

The complete audio monitoring latency of a configuration, often referred to as the roundtrip latency, is the sum of:

• AD converter latency
• Input portion of the I/O buffer
• Audio driver latency
• Output portion of the I/O buffer
• DA converter latency

When just doing playback, of course you don’t have to go trough all of these and the latency is the sum of:

• Audio driver latency
• Output portion of the I/O Buffer
• DA converter latency

Now, let’s move on to the actual test:

These where the candidates:

Focusrite Pro40 (FW)
RME Babyface (USB)
RME Fireface 800 (FW)
“Lynx Aurora 8 (FW)” Didn’t get this to speak well with OSX 10.7.1, or I had the wrong break-out cable.

Focusrite ISA 828 (ADAT)

I tested the I/O-latency by running a cable from the output to the input and measuring the delay with a program called MaxMSP.

I used a MacBook Pro 6,2 (15″ mid 2010), 2,66GHz intel core i7, 4 GB 1067 MHz DDR3 ram, running Mac OS X Lion 10.7.1 (11B26).

I/O vector size and signal vector size as described in the MaxMSP manual:

• The I/O Vector Size (I/O stands for input/output) controls the number of samples that are transferred to and from the audio interface at one time.
• The Signal Vector Size sets the number of samples that are calculated by MSP objects at one time. This can be less than or equal to the I/O Vector Size, but not more. If the Signal Vector Size is less than the I/O Vector Size, MSP calculates two or more signal vectors in succession for each I/O vector that needs to be calculated.
• With an I/O vector size of 256, and a sampling rate of 44.1 kHz, MSP calculates about 5.8 milliseconds of audio data at a time.

The I/O Vector Size may have an effect on latency and overall performance. A smaller vector size may reduce the inherent delay between audio input and audio output, because MSP has to perform calculations for a smaller chunk of time. On the other hand, there is an additional computational burden each time MSP prepares to calculate another vector (the next chunk of audio), so it is easier over-all for the processor to compute a larger vector. However, there is another side to this story. When MSP calculates a vector of audio, it does so in what is known as an interrupt. If MSP is running on your computer, whatever you happen to be doing (word processing, for example) is interrupted and an I/O vector’s worth of audio is calculated and played. Then the computer returns to its normally scheduled program. If the vector size is large enough, the computer may get a bit behind and the audio output may start to click because the processing took longer than the computer expected. Reducing the I/O Vector Size may solve this problem, or it may not. On the other hand, if you try to generate too many interrupts, the computer will slow down trying to process them (saving what you are doing and starting another task is hard work). Therefore, you’ll typically find the smaller I/O Vector Sizes consume a greater percentage of the computer’s resources. Optimizing the performance of any particular signal network when you are close to the limit of your CPU’s capability is a trial-and-error process. That’s why MSP provides you with a choice of vector sizes.

—–

Babyface (USB), 44,1kHz, Line (XLR):

I/O vector size: 16, Signal vector size: 16 = 171 samples = 3.877551 ms
I/O vector size: 32, Signal vector size: 32 = 203 samples = 4.603175 ms
I/O vector size: 64, Signal vector size: 64 = 267 samples = 6.054422 ms

I/O vector size: 1024, Signal vector size: 1024 = 2187 samples = 49.591835 ms

Babyface (USB) + ISA 828, 44,1kHz, Line (XLR):

I/O vector size: 16, Signal vector size: 16 = 170 samples = 3.854875 ms
I/O vector size: 32, Signal vector size: 32 = 202 samples = 4.580499 ms
I/O vector size: 64, Signal vector size: 64 = 266 samples = 6.031746 ms

I/O vector size: 1024, Signal vector size: 1024 = 2186 samples = 49.56916 ms

Babyface (USB), 48kHz, Line (XLR):

I/O vector size: 16, Signal vector size: 16 = 171 samples = 3.5625 ms
I/O vector size: 32, Signal vector size: 32 = 203 samples = 4.229167 ms
I/O vector size: 64, Signal vector size: 64 = 267 samples = 5.5625 ms

I/O vector size: 1024, Signal vector size: 1024 = 2187 samples = 45.5625 ms

Babyface (USB) + ISA 828, 48kHz, Line (XLR):

I/O vector size: 16, Signal vector size: 16 = 170 samples = 3.541667 ms
I/O vector size: 32, Signal vector size: 32 = 202 samples = 4.208333 ms
I/O vector size: 64, Signal vector size: 64 = 266 samples = 5.541667 ms

I/O vector size: 1024, Signal vector size: 1024 = 2186 samples = 45.541668 ms

Babyface (USB), 96kHz, Line (XLR):

I/O vector size: 16, Signal vector size: 16 = 140 samples = 1.458333 ms
I/O vector size: 32, Signal vector size: 32 = 263 samples = 2.739583 ms
I/O vector size: 64, Signal vector size: 64 = 327 samples = 3.40625 ms

I/O vector size: 1024, Signal vector size: 1024 = 2247 samples = 23.40625 ms

Babyface (USB) + ISA 828, 96kHz, Line (XLR):

I/O vector size: 16, Signal vector size: 16 = 140 samples = 1.458333 ms
I/O vector size: 32, Signal vector size: 32 = 263 samples = 2.739583 ms
I/O vector size: 64, Signal vector size: 64 = 327 samples = 3.40625 ms

I/O vector size: 1024, Signal vector size: 1024 = 2247 samples = 23.40625 ms

Babyface (USB), 192kHz, Line (XLR):

I/O vector size: 16, Signal vector size: 16 = 116 samples = 0.604167 ms OUTPUT HAS POLARITY REVERSED
I/O vector size: 32, Signal vector size: 32 = 228 samples = 1.1875 ms OUTPUT HAS POLARITY REVERSED
I/O vector size: 64, Signal vector size: 64 = 422 samples = 2.197917 ms OUTPUT HAS POLARITY REVERSED

I/O vector size: 1024, Signal vector size: 1024 = 2342 samples = 12.197917 ms OUTPUT HAS POLARITY REVERSED

Fireface 800 (FW400 -> 800), 44,1KHz, Line:

I/O vector size: 16, Signal vector size: 16 = 219 samples = 4.965986 ms
I/O vector size: 32, Signal vector size: 32 = 251 samples = 5.69161 ms
I/O vector size: 64, Signal vector size: 64 = 315 samples = 7.142857 ms

I/O vector size: 2048, Signal vector size: 2048 = 4283 samples = 97.120178 ms

Fireface 800 (FW400 -> 800) + ISA828, 44,1KHz, Line:

I/O vector size: 16, Signal vector size: 16 = 213 samples = 4.83 ms OUTPUT HAS POLARITY REVERSED
I/O vector size: 32, Signal vector size: 32 = 245 samples = 5.555555 ms OUTPUT HAS POLARITY REVERSED
I/O vector size: 64, Signal vector size: 64 = 309 samples = 7.006803 ms OUTPUT HAS POLARITY REVERSED

I/O vector size: 2048, Signal vector size: 2048 = 4277 samples = 96.984123 ms OUTPUT HAS POLARITY REVERSED

Fireface 800 (FW400 -> 800), 48KHz, Line:

I/O vector size: 16, Signal vector size: 16 = 219 samples = 4.5626 ms
I/O vector size: 32, Signal vector size: 32 = 251 samples = 5.229167 ms
I/O vector size: 64, Signal vector size: 64 = 315 samples = 6.5625 ms

I/O vector size: 2048, Signal vector size: 2048 = 4284 samples = 89.25 ms

Fireface 800 (FW400 -> 800) + ISA828, 48KHz, Line:

I/O vector size: 16, Signal vector size: 16 = 213 samples = 4.4375 ms OUTPUT HAS POLARITY REVERSED
I/O vector size: 32, Signal vector size: 32 = 245 samples = 5.104167 ms OUTPUT HAS POLARITY REVERSED
I/O vector size: 64, Signal vector size: 64 = 309 samples = 6.4375 ms OUTPUT HAS POLARITY REVERSED

I/O vector size: 2048, Signal vector size: 2048 = 4277 samples = 89.104164 ms OUTPUT HAS POLARITY REVERSED

Fireface 800 (FW400 -> 800), 96KHz, Line:

I/O vector size: 16, Signal vector size: 16 = 188 samples = 1.958333 ms OUTPUT HAS POLARITY REVERSED
I/O vector size: 32, Signal vector size: 32 = 348 samples = 3.625 ms
I/O vector size: 64, Signal vector size: 64 = 412 samples = 4.291667 ms

I/O vector size: 2048, Signal vector size: 2048 = 4380 samples = 45.625 ms

Fireface 800 (FW400 -> 800) + ISA828, 96KHz, Line:

I/O vector size: 16, Signal vector size: 16 = 189 samples = 1.96875 ms
I/O vector size: 32, Signal vector size: 32 = 347 samples = 3.614583 ms
I/O vector size: 64, Signal vector size: 64 = 411 samples = 4.28125 ms

I/O vector size: 2048, Signal vector size: 2048 = 4379 samples = 45.614582 ms

Fireface 800 (FW400 -> 800), 192KHz, Line:

I/O vector size: 16, Signal vector size: 16 = 166 samples = 0.864583 ms
I/O vector size: 32, Signal vector size: 32 = 326 samples = 1.697917 ms
I/O vector size: 64, Signal vector size: 64 = 598 samples = 3.114583 ms

I/O vector size: 2048, Signal vector size: 2048 = 4566 samples = 23.78125 ms

Fireface 800 (FW400 -> 800) + ISA828, 192KHz, Line:

I/O vector size: 16, Signal vector size: 16 = 166 samples = 0.864583 ms
I/O vector size: 32, Signal vector size: 32 = 326 samples = 1.697917 ms
I/O vector size: 64, Signal vector size: 64 = 598 samples = 3.114583 ms

I/O vector size: 2048, Signal vector size: 2048 = 4566 samples = 23.78125 ms

Pro40, 44.1Khz, Line:

I/O vector size: 16, Signal vector size: 16 = 5.827664 ms
I/O vector size: 32, Signal vector size: 32 = 6.55328 ms
I/O vector size: 64, Signal vector size: 64 = 8.004535 ms

I/O vector size: 2048, Signal vector size: 2048 = 97.981857 ms

Pro40 + ISA828, 44.1Khz, Line:
I/O vector size: 16, Signal vector size: 16 = 6.485261 ms
I/O vector size: 32, Signal vector size: 32 = 7.210885 ms
I/O vector size: 64, Signal vector size: 64 = 8.662131 ms

I/O vector size: 2048, Signal vector size: 2048 = 98.639458 ms

Pro40, 48Khz, Line:
I/O vector size: 16, Signal vector size: 16 = 5.354167 ms
I/O vector size: 32, Signal vector size: 32 = 6.020833 ms
I/O vector size: 64, Signal vector size: 64 = 7.354167 ms

I/O vector size: 2048, Signal vector size: 2048 = 90.020836 ms

Pro40 + ISA828, 48Khz, Line:
I/O vector size: 16, Signal vector size: 16 = 5.958333 ms
I/O vector size: 32, Signal vector size: 32 = 6.625 ms
I/O vector size: 64, Signal vector size: 64 = 7.958333 ms

I/O vector size: 2048, Signal vector size: 2048 = 90.625 ms

Pro40, 96Khz, Line:

I/O vector size: 32, Signal vector size: 32 = 5.541667 ms
I/O vector size: 64, Signal vector size: 64 = 6.208333 ms
I/O vector size: 128, Signal vector size: 128 = 7.541667 ms

I/O vector size: 2048, Signal vector size: 2048 = 47.541668 ms

Pro40 + ISA828, 96Khz, Line:
I/O vector size: 32, Signal vector size: 32 = 5.916667 ms
I/O vector size: 64, Signal vector size: 64 = 6.583333 ms
I/O vector size: 128, Signal vector size: 128 = 7.916667 ms

I/O vector size: 2048, Signal vector size: 2048 = 47.916668 ms

—–

Note that hardware with very slow transient response may decrease accuracy of measurement.

When I connected the adat cable and the ISA was at 192kHz when I turned it on, I got super system failure …

Here are some graphs, x=buffer size, y=latency in milliseconds:

—–

One parameter I didn’t realize until later I should have measured is how different sound cards handle low latency also called LLP (Low Latency Performance), I didn’t record any numbers for this, as I didn’t know how to do it, but I experienced that the RME Babyface handled low buffer sizes quite well compared to the other cards, I used the “test section” in Ableton Live, which simulates a certain cpu-usage and lets you listen to a test tone and hear if there are any drop-outs.

I also experienced that I could increase the sampling rate, thereby lowering the latency which is defined by samples in the buffer size, and still get good performance from the test tone. Any thoughts on sampling rate vs buffer size and how this affects the performance of the system? why choose low sampling rate and low buffer size, instead of high sampling rate and high buffer size, if they result in the same amount of latency? To get an answer to this and the concept of LLP, I had to seek help amongst other nerds at gearslutz.com and I stumbled upon this forum thread where they answered me on my issue on buffer size vs sampling rate:

“TAFKAT”:

Raising the sample rate not only effects the latency value but also increases the overhead in DSP processing , throughput and data file sizes so its a balancing act. For those needing to work at the higher sample rates the usual practice is to raise the buffer sizes accordingly to compensate for the increase in processing overhead. There is no real advantage to increase the sample rate simply to lower the latency value if the higher sample rates are not specifically required for the project IMO.

“tuRnitUpsuM”:

(…) Higher sample rates do not equal lower latency in the bigger picture when you (action <> reaction) have to raise buffer values to compensate for increased DSP data overflow. Data size increases, time value increases to process the change. Whats gained on the front end – is lost on the back end.

My response:

Are these relations linear? From the numbers I ended up with, I got the impression that they’re not. Would there be any reason to measuring the sound cards LLP at different sample rates and see if the performance/sample-ratio is the same?

For example: would a setup running 44.1KHz with a buffer size of 16 samples perform exactly equally to a setup running 88.2KHz with a buffer size of 32 samples on the same computer?

“Timur Born”:

There is a linear correlation and a non-linear one.

Linear: Double the sample-rate at double the audio buffer size equals exactly the same audio buffer latency.

Linear: Double the sample-rate equals exactly double the data/bandwidth the CPU + RAM + HD need to process, which at double the audio buffer size equals about half the number of tracks/fx being usable.

Non-linear: AD/DA conversion is faster (=lower latency) with higher sample-rates. But we are talking about a maximum of 2 ms here, usually less.

Non-linear: Your computer (CPU + RAM + HD) may not be able to deal with the number of “theoretically” possible tracks/fx, so either you may not get double the tracks/fx at half the sample-rate or may not get half the number of tracks/fx at double the sample-rate.

“TAFKAT”:

I don’t believe it will remain linear with the number of Plugins/Polyphony when using a higher sample rate at double the buffer to maintain the same latency, as the system still has to deal with the higher processing associated with the higher sample rate.

It may be interesting to get an empirical value to the exact scaling variable , I have some 96K alternate sessions of DAWbench DSP that I will give a run up when I get some time and see what it tips up.

They also had developed quite an extensive database of the LLP’s of different audio interfaces. They used a benchmark program called DAWbench DSP to measure the LLP, keep in mind that some of these cards are high speed PCI cards (which soon is available to laptops trough thunderbolt expansion bays) and not USB or FW cards:

I made a more graphical presentation of the mentioned LLP rating values, the numbers are all just in linear relevance to the best card, higher is better:

When researching on latency, after this point, it starts to get quite technical and the more I learn, the more I realize I don’t know. I feel that for now, I know enough about the subject to understand the latency and DSP performance of my current setup. I’ve learned that latency is not as relevant as I originally feared, and that there is more to the concept of latency and DSP than I thought.

The post Equipment Standard – Audio latency appeared first on Drums and electronics.

Bendik Hovik Kjeldsberg is studying composition at the same Academy as I am doing my master degree.

He asked me to perform one of his compositions with him.

Since the composition’s nature is very electronic it presented some challenges when we were to perform it.

Listen to the composition here, keep in mind that this is intended to be a score and that the actual composition is what we perform based on this:

After some intents to solve this with Ableton Live, I decided the best way would be to just use MaxMsp for this project. I’ll elaborate later in the following text.

The first “blipp”-sounds that appear I wanted to play by triggering them one at a time in a sequence. In Ableton I could slice the track to MIDI on it’s transients, then extract each section, put them one after another in an audio track as clips, than map the MIDI-signal generated from the amplitude of the input signal to “next scene” and set global quantization to “none”. But it is quite self-explanatory that this is not particularly favorable.

As an alternative I tried to figure out how to do transient-detection on an audio file in Max, and then play the transients one after another, but I ended up manually putting all the transients locations in millisecond format in a [coll] object, then triggering them one at a time trough a [play~] object.

I’ve been looking into the [slice~] object, but I haven’t quite figured it out yet.

I’m extremely open for suggestions on this subject.

Our main intention with the performance of the piece was that the sounds Kjeldsberg had created in advance should be our instrument and what we performed should only be based on the mentioned composition and not contain any backing tracks. We achieved this using the following methods:

– All the sounds Kjeldsberg wanted to use where broken apart to as small pieces as we saw convenient.

– All drum sounds that I could manage to play at one time where removed from Kjeldsbergs setup.

– Sounds that were layered with these drum sounds were triggered by the corresponding drum using this max patch I made.

– Since the mentioned layered sounds changed during the performance, I added the ability to in real time change the sound that were to be triggered.

…

Kjeldsberg wanted to play both a melody line and a bass line at the same time with one one hand while triggering samples with the other hand.

Since the melody and bass line were not unison, that presented a challenge.

Bendik wanted to play the top melody line shown in the picture bellow while triggering the corresponding bass notes. We could of course have triggered a clip containing the bass notes in a certain tempo he would have to follow, but then we would loose his unique phrasing.

So I made a Max for Live patch that triggers each notes corresponding bass notes (some of the top notes are harmonized with different bass notes) in the right sequence, only problem is that the performer have to press a “reset sequence”-button for each time he or she plays it. I could have had the sequence restart when the last note is played, but we figured out that this was the easiest and most convenient method in this context.

…

I enjoy this way of interpreting a composition since it’s a lot like how I’ve been working earlier when extracting sounds from pieces I like. But then again this IS the actual composition as the composer intended it to be, in earlier examples I’ve only extracted sounds to make them part of a new, improvised piece.

In a way this is like going back to the original way of composing, where the composer didn’t make the final auditive experience, but rather a score for the performers or conductor to interpret. And since there are not yet instruments capable of making most of these sounds, we have to modify our own instruments to perform the composers intentions. Again, this is a fairly strange thought, since it is some how comparable to that some one writing a piano piece before the piano was even invented. This also incorporates the role of the instrument maker into what’s expected from the performer and/or the composer.

Here is a video from a concert where we perform the piece (the picture gets more descriptive at 2:00):

The post Performing an electronic composition appeared first on Drums and electronics.

The whole session was improvised. I used only my computer running Ableton Live. I put the speakers by the wall which is made of different sized metal plates, they added some resonance to the music.

I sent all audio wirelessly to the speakers via my iPhone and an ad-hoc network. This gave the impression that I was not actually making the music and resulted in an interesting setting were people were reacting to the performance without knowing it was done live.

The post Music – Ambience Project appeared first on Drums and electronics.