Soniccouture has started an interesting crowd-source project called CrowdChoir.

We are going to build a unique sampler instrument  – a choir / vocal ensemble made with hundreds of voices from all around the world.

We need a a minimum of 500 notes to layer in the instrument, so please help us if you can.

Everybody that sends us a recorded note will receive the CrowdChoir instrument free, in Kontakt /EXS & Ableton Live format.

The project will run for 2 months, until March 31st 2012

One participant chosen at random will receive a custom-made, 5 octave cherry-wood bcustom array mbra (worth $2000)

You can register for the course here, and make sure to use the discount code designingsound20% during checkout.

Here is a brief description of the workshop (full description is available here):

SOUND & MUSIC TECHNIQUES FOR NARRATIVE FILMMAKING with Gustavo Costantini Saturday 28th & Sunday 29th January 2012 10.30am-5.30pm – £200  – This essential 2-day workshop aims to equip filmmakers with a better understanding of how sound and images are used in filmmaking. Rather than the blank coverage approach now demanded of many sound editors, designers and re-recording mixers, tutor Gustavo Costantini advocates soundtracks to be full of ideas rather than effects. Participants will learn key elements of sound/image strategies and be introduced to all the possible uses of sound and music in film. Extensive use of film clips ranging from THE BIRDS to SAVING PRIVATE RYAN will demonstrate how difficult it is to think in terms of sound and music and how neglected these fields still are. Exclusive material provided by Academy Award-winning Sound Editor Walter Murch will be used to reveal his working methods on the assembly of sound design and film editing. This unique footage will also show the collaboration between Murch and Anthony Minghella on the opening sequence of THE TALENTED MR RIPLEY, from first assembly to the final version.

The society of sound editors also presents two non-competition awards each year, Filmmaker and Career Achievement. For 2012 a producer of countless blockbusters Gale Anne Hurd will be accepting the Filmmaker Award and for Career Achievement Supervising Sound Editor George Watters II is bestowed with the honor.

The Awards will be held on February 19th, one day after the CAS awards and one week before the Oscars. Congrats to all the nominees.

The Sound of Hotel for Dogs.

The Cinema Audio Society announced nominees for their 48th annual awards show celebrating outstanding achievements in Film and TV mixing. In addition, every year the CAS presents a “Career Achievement Award” to a deserving mixer, bestowing Re-recording mixer Scott Milan with the honor in 2012. Milan is currently finaling “Hansel and Gretel: Witch Hunters”, which will be the first film mixed at Technicolor’s new Paramount on-lot facility.

That said, the big news for this year’s CAS awards is that scoring mixers are to be nominated along with their fellow production and re-recording mixers. Below are the CAS nominees for sound mixing, motion picture. Head over to the CAS website for the rest of the nods.

• HANNA - Roland Winke, Christopher Scarabosio, Craig Berkey, CAS, and Andrew Dudman.
• HUGO – John Midgley, Tom Fleischman, CAS, and Simon Rhodes.
• MONEYBALL – Ed Novick, Deb Adair, CAS Ron Bochar, CAS, David Giammarco, and Brad Haenel.
• PIRATES OF THE CARIBBEAN: ON STRANGER TIDES – Lee Orloff, CAS Paul Massey, CAS Chris Boyes, and Alan Meyerson.
• SUPER 8 – Mark Ulano, CAS, Andy Nelson, Anna Behlmer, and Dan Wallin.

Andy Farnell – a familiar name in computer audio – is a computer scientist, sound designer, author and a pioneer in the field of procedural audio. He is a visiting professor at several European Universities and a consultant to game and audio technology companies. His book, ‘Designing Sound‘, is a bible for procedural sound and should be on your bookshelf, if it isn’t already!

He was very kind to find time in his busy schedule when I visited London, and we talked about what procedural audio is, where it stands now and what it can be in the future. This article is a transcription of our conversation, which he was again very kind to edit along with me. It was no easy task because there was so much good content!

Thank you Andy!

DS: Where does Procedural Audio stand now? Would you say it is comparable to where CGI was in the 70s/80s, when computers weren’t powerful enough?

Andy: That is a central mythology – that the computers aren’t powerful enough to do it. This is often brought out as a straw man argument against Procedural Audio by skeptics. One of the things I did with my 2005 demo was to make all of the sounds (they weren’t very high in quality) that you would need for a first person shooter game – fire, water, wind, rain, some animals, some footsteps, some guns, some vehicles. This was 2005 and I had them all running on a 533 MHz processor generating a realistic-ish sort of soundscape to prove that if you had 1GHz processor and if you used half of it for the graphics then it would be quite possible to synthesise all the sounds using the remainder. Six years after doing that people would still come to me with this straw man argument, they would say, “You know Andy, we love this Procedural Audio stuff but there’s just not enough CPU available”. But we now have two to the five times more CPU than when I did my 2005 proof-of-concept demo. So, what’s behind that? Why are they saying that? It’s not true. What happens is the internal politics of resources. The requirements always expand to fit the resources available. The game worlds get bigger and bigger and the graphics get more and more demanding. The audio team will always have the least amount of CPU allocated to them as an afterthought, because in the current structural model of production sound is “post production”, and no body wants to commit to giving audio that much CPU bandwidth. I feel that is the real reason behind the argument. You often get these straw man arguments that enter in to a culture and just get recycled. People know that there is an argument and it comes to their tongue very quickly and they say “Yes we could do it but there is not enough CPU”. With the left over CPU on a modern games console I could provide you great procedural sound.  On an eight core architecture, we would need one or two CPU cores to give procedural sound. Even more interestingly is what happens when we run models in GPU, and many Procedural Audio models are inherently parallelisable. So, yes, Procedural Audio is somewhere in that era before the Tron movie, or before the Pixar CGI revolution, its possible, but not yet seen as viable, perhaps the shift is too painful for big companies to make.

DS: Have you tried doing a similar demo using today’s technology?

Andy: No. I just don’t have time at the moment. Life is moving so quickly and I’m involved in so many other interesting projects. Some of them to do with computer science, some of them to do with philosophy. Interesting times, but in the future I want to have a research department and have a bunch of guys, really smart guys who are just on this and want to do it and I can help direct their research. Because, when you look at what Procedural Audio breaks down in to, its actually very deep specialisations – just like CGI. There is room for intense talents within the area. Let us make use of CGI analogy again – if you are a real good texture artist you are great at looking at skin and saying, “That is the skin of a 40 year old, that is a skin of a particular kind of salamander, look at the way the bone structure moves underneath it, look at the way the light hits it”. You get specialisations within Procedural Audio which would be people who are very good at fluids, they are great at doing water falls and drops of water and boiling mud and lava. They understand that sound. They are able to model it and come up with great sounding objects and great processes that do it.

Before I took up this umbrella term, this banner of Procedural Audio, and tried to make a focussed idea out of it, I had mentors – I mean people I looked up to, leaders with ideas that nobody else was doing in industry or academia people like Perry Cook. He is like the grandfather of Procedural Audio. He was doing it in the early 90s, when the argument that there wasn’t enough CPU really was a good argument [laughs] and then after him came Dinesh Pai and Kees van den Doel and they worked on impacts and fluids. They did that as very narrow academic work. I don’t know if they saw (the generality of the possibilities) that the water could be taken and integrated with a glass so we get an object that could be filled up or emptied, or become raindrops in a particle based weather system that interacts with different objects the rain falls on… The object-object interaction based idea of “sounding objects” really came out the North Italian schools, otherwise we just have event driven sample playback . But, they did extremely good work and a lot of my stuff is just interpreting their work and generalising, extending it, and making a coherent philosophy of sound as process rather than data. We must always be mindful of that background to it. It didn’t just pop out of the air. It is a project that has been in the background (since Mathews in the 50′s)  growing slowly. If anything, I have  been a very vocal advocate of these ideas applied to the general case of everyday sonic simulation, and been instrumental in defining what procedural audio is.

DS: So the obstacles aren’t purely technological?

Andy: I don’t know what the “real obstacles” are now. I’ve said in another interview before, that around 2006-2007 it dawned on me that there weren’t any fundamental obstacles to radical technical progress. We could do this. The obstacles were structural and political. How do you introduce a new technology? How do you get people to take risks on that? One of the weaknesses of it, it’s a weakness but a very deep philosophical strength (and this is quite subtle), is that sound as data fits in to a capital model. Intellectual property allows you to own a sound asset. So if you record or create a sound, it is an asset that you own. You can trade assets. But procedural model breaks with an ownership model because what you are doing is you are substituting general sounding objects for something we can make million sounds in the future. There is no redundancy built in.

DS: Although, if a game developer spent time and resources building a procedural audio engine, as they would spend time building an audio engine, wouldn’t it be an asset that could be owned?

Andy: The observation there is that the code is the asset. But the code is useless without a group of people who understand how to make it sing. We move the value from residing in the thing itself to how it is used. I see procedural audio as an art to be practiced, not just an application layer to be built.

DS: So even with Procedural Audio you will need a sound designer to understand what it can sound like and how it can impact a player/end user?

Andy: I think this was on the game audio forum or something years back. Someone raised the accusation at me that, “Guys like you put people like us out of business and you are making technology that is going to replace our art”. I took that on board as a very valid point. Being a sound designer myself, the last thing I want to do is put other sound designers out of work. I see it as a liberating step – you have your sound samples and you have this. I always see it as a complimentary technology and not a replacing technology, that is point number one. Point number two that is more important is that every new technology that comes along generates a new requirement for skillets which the talented people in that business become really good at. So every Procedural Audio team would need a good sound designer.  I wouldn’t leave it to the programmers, I want somebody who has a great set of ears and I would actually put them in a higher position and get them to direct the programmers and say, “No its more like this, listen to these examples. I want to get this emotion across”, and they can direct it aesthetically. It’s not really putting sound designers out of work and it is not a totalitarian project. This is why I worry that the bean counters, the alienating/asset-oriented capitalists, are seduced by this kind of technology because they just think, “Well we plug that in and we get rid of the sound department”. That’s not what I want to see happen. One of the great advantages is that it gives 90% of your assets for free. You just put your objects in the world and you get default sounds. What that means is that you don’t have to worry about an asset-event matrix any more. You don’t have to worry that somebody has forgotten to put a sound on something because everything will be covered by default and now the sound designer is liberated not to be thinking up every single little rock sound but to go and focus on the emotionally significant sounds – the hero’s sword, the getaway car, the gun sound. They can put all their time and energy in to getting those right and not have to worry about the other stuff. That’s another argument for Procedural Audio. It raises the bar from where you start from.

DS: So, Procedural Audio is just another tool in the arsenal of a sound designer? A combination of different techniques?

Andy: Procedural Audio is a philosophy about sound being a process and not data. In its broadest sense, if I were to say it is the philosophy of sound design in a dynamic space, and the method is as irrelevant to Procedural Audio as whether you use oils or water colours is to painting. If you use papier-mâché and glue or whatever is to sculpture – the end is in the artist and not the method. So you can mix and match the methods, they exist separately. In the industry now, all the successful Procedural Audio is mixed methods of samples – granular methods with the exception of as far as I can see of Nick Fournel’s work which is basically a similar kind of resynthesis but it is phaselet or PVOC type re-synthesis. First lets see why that happens. There is obviously a clear bridge there between existing technologies and the direction that Procedural Audio can go in. It gives you an immediate start. You can use your existing sample libraries and your guys out in the field. I incorporate this in to my understanding of Procedural Audio as: your sound guys now do analytical recording, not for the purpose of using those as final products but for exposing and analysing the sound underneath so you can build your procedural model. Granular methods are a very direct way of doing that. You just take the input sound and bust it up in to its component waveforms and then you re-synthesise them as grain clouds in different ways. Or in the phase vocoder or linear predictor sense you split them up into transient-exciter components and resonant parts. In that sense it is a direct re-synthesis. Now these approaches that have a method and analyses part, in effect, have a one to one mapping. So you are doing re-synthesis but you can fiddle around with the parameters in the middle. I call this a shallow or phenomenal approach. What it means is that is that the way in which you can change the sounds is limited mostly by your understanding of the parametric interface of the re-synthesis method. The re-synthesis method doesn’t capture any of the physics, it doesn’t capture any of the process of the sounds. Whereas building a procedural model, where you got a model and a method which compliments the model, you are  interested in the behaviour of the sound that is built in to your model. That is not phenomenal. That is not surface, I call that essential or deep. Guys who are doing that kind of thing are like Zheng and James, they are using really accurate models. They are basically doing what computer scientists mean when they say computer modelling. They are using fluid dynamic models to model fluids. They need a rack of computers that take days to process a few seconds of sounds, its not practical Procedural Audio, as would be used in games, because it does not meet the real time criteria for a start. At least not yet.

But having said that I also think there is another side of (non  real-time) Procedural Audio which is not in computer games. It’s in animation, where the idea is that once we have introduced the sounding objects as models, into the scenes, sound ceases to be post production. You re-arrange the objects and their behaviour in your scene to do your visuals and the sounds come out for free. You can even change the location of the microphone virtually after the fact. This is the future of cinematic sound , CGA or computational audio. The best thing about this is that we can drop the real time constraint and  trade speed for quality.  Why not have thunder rendered with one with a million N-waves, which sounds more like the real thing but which takes a long time to compute because you have got a render farm and you are a million dollar Pixar type company? You need good model programs and lots of computing resources but you don’t care about the real time thing. I think Procedural Audio encompasses that as an art.  Skywalker once kindly offered me computing resources, I think Randy Thom set it up, but its hard to work remotely out of context, I would like to put a masters student or PhD on that one day, I grew up with that rather dangerous Radiophonic workshop ethos of Oram/Derbyshire  (two original women sound designers),  creative research and commercial production combined, it is an iconoclasm of experts, expectations and traditions. Much too risky for todays world.

DS: Much about sound design is about achieving hyper reality and not reality. You wouldn’t want a gun to sound like a real gun. So is Procedural Audio about creating realistic models and building on them to achieve hyper realism?

Andy: Amongst the many good sound designers that I have met, they all turn out to be really quite well rounded smart people. They aren’t purely phenomenal,  see the world not only through an artists gaze, but an informed, worldly apprehension. Sound is about going in to the world, what happens inside and outside things, its about deep knowledge about how things work and what does that mechanism mean to your emotions. I think the role of what a sound designer is becomes somebody who’s language is not about computers but understanding the mechanisms of sounds. And the  natural progression for sound designers, when they run out of all the shiny plugin technology in the world is Procedural Audio because it lets their art develop, connecting with sound and its causes and its propagation and reflection. Deep knowledge of sound is what a sound designer has, even when they can’t express or vocalise it. People who have become really talented at that often have hidden knowledge, ineffable knowledge, they don’t have a way to vocalise it or make it explicit but they understand things intuitively and you see them in the studio just do stuff and if you ask them how they did it, they would go “I don’t know, I knew thats what was needed” and it gives them, I don’t like the word, but it gives them a “rationale” to explicate their knowledge about sounds.

DS: How does Procedural Audio fit in to this? Most sound designers aren’t mathematicians or scientists, most of them have a good understanding of how objects react in the world but not necessarily the science behind it.

Andy: In the very long run and I’m talking about – I hope to see it in my life time – ten, twenty, thirty, forty years in the future I think all of this that we are talking about today will be well understood as part of the discipline of sound design. I think the philosophy of Procedural Audio will be a part just as much an artist now can talk about textures and different kinds of lighting. In a way sound is a real throwback, right now. Some people have said to me, “Sound technology is fifteen-twenty years behind graphics technology”. That’s crazy, all of the algorithms that made visuals possible came out of sound. One dimensional signals first and then two and three.. it comes from radio and radar. And, somehow culturally, sound got left behind. Because, we are visual beings and we put all our energy in to manipulating and creating ways to have a visual reality. Twenty-thirty years in the future all of what we are saying now will be a part of the language of sound design. But right now, theres a fork in the road between my understanding of it – the philosophy and the way it should go and the way it will go practically – and what is happening. So part of my philosophy in education is principles not products. It’s a reaction against the commodification of skills and people, techniques, arts being reduced to products. So if you look on the sound design list when somebody says, “How do I make such and such a sound”, and somebody else says, “Oh you need the zzaaaq plugin, that does that”, and they completely abdicate any desire for knowledge. They don’t even care (to pay for it) because they can get it off bit torrent anyway. Somebody else has packaged that capability and knowledge and given it to them. And by doing that they have robbed them of the knowledge, (Zarathustra says: be careful what I give you as a gift, because I may take something away from you) the knowledge is useless by itself but as for an artist, for your career, your development, for your ability to do things, that knowledge is important, its part of it. Both the commercial approaches to Procedural Audio at the moment, and this isn’t dissing these guys (in Audio Gaming and Sony… I am in touch with Amaury quite a bit and try to help them out recruiting and seeing the way ahead), what they are interested in producing is products (that is business). They want Procedural Audio models as drop in objects in the game. With this model, given to the current middleware developers, you’ll probably have opaque Procedural Audio objects, you cant see inside them, they have a few exposed parameters. Say you have a car and you can choose four or six cylinder engine, a bunch of different configurations for the exhaust, you can choose the body material, the tyre and that would be it. That is good! That is how you want your end user to see the object. At a certain level. So one approach would be to sell these as closed objects, with their functionality is hidden. But, for me as an “academic”, as a pioneer I am much more interested in enabling (my relationship is with the sound designer, with people), you should get in to this stuff. To me, the good stuff will be toolkits like the kind Dylan Menzies and others have proposed  (and using the pluggable physical components using FEM/discrete numerical difference schemes like Stefan Bilbao explicates) Now you have an engine model and its a part of the car and you can replace the engine – real world analogy here – you can tinker, you can take it apart and change the the way the camshaft and the pistons work. You can replace the method that is used for that engine with a subtractive method that you wrote in C++ and drop it in because there is a well defined interface. And the kind of well defined interfaces that work are like data flow interfaces – like Max/MSP and Pure Data type interfaces where you can just plum these objects together very quickly in the studio and test them in-world while playing. Ultimately, open ended data-flow user interfaces with efficient JIT /bytecode compilers are the future for creative Procedural Audio. Then you will have a very vibrant community, a vibrant ecosystem of programmer-sound designers and sound designer-programmers and people who work in teams and Procedural Audio will be a vibrant technology. But I think first it will go through what basically becomes a plugin (mystified) culture. Procedural Audio in my (wishful) philosophy is open and based around knowledge [laughs]. That will come with time after these products have driven a path and we will think about sound differently. The construction of sounds will be more technically informed and richer than saying, “Oh yeah, Hollywood Edge track 6 number 4, that’s the one you need”.

DS: Would you relate the questions raised about Procedural Audio to people talking about motion capture replacing actors?

Andy: I never made that connection, that’s really good. Mo-cap in relation to CGI is the same as what I am calling analytical recording for Procedural Audio. You go out in the field and try and look at the behavioural features and try and capture them and then use them as data.

DS: So would that be the important point to make then? To use the analysis as data and not exactly copy it, just as how mo-cap is used in CGI?

Andy: Yeah, I was talking to some guys who are in to this mo-cap and human face stuff recently and they were telling me some amazing things about how Tom Cruise voiced an animated character and they got all his face expressions – the eye brows and everything. The trouble was it was a dog character or something and when they played it back it looked too much like Tom Cruise [laughs] – and this was how you could extrapolate to hyper reality where you just scale everything so that the eye brows doubled the distance. So they got this super hyper real version of Tom Cruise in the character but somehow you still knew it was him. This is built in to procedural technologies and data analytical technologies. You can create models based on interpretations of real data and then extrapolate that off in to hyper reality and thats really powerful in film and games. You want that capability built in. They were doing something else really weird, like they were morphing characters, they were doing something like Sigourney Weaver and Tom Cruise and you make Sigourney Cruise. Like you do with hidden Markov models in composition where you can hybridise them and you can kind of have Beethoven and Shostakovich and get new ones, Shothoven or Beethovich (??) [laughs] or what ever your new composer is.

DS: The obvious use of Procedural Audio is gaming and animation, as you mentioned. Where else do you see it being applied? There has been some talk of it being used in electric cars to simulate engine sounds.

Andy: I can see it as a real interesting safety feature in a car. I would also worry about this becoming a real nuisance – imagine a car running along the street sounding like a clown’s car and the person is drunk and its 3 in the morning! I can see a lot of social tension about objects having arbitrary sounds. Sound can be very intrusive and it has very different implications across different cultures and age groups.

DS: I came across a Harmon owned company called HALOSonic that promises to deliver technology that seems to simulate engine sounds for ‘cars of the future’. While there is very little information on the actual technology being used, I wouldn’t be surprised if it used Procedural Audio.

Andy: Let us analyse that as a product and say why Procedural Audio is really powerful for something like this. On the face of it you would think of using samples. I am the CEO of the company, I want a cheap product and I want to get it out. RAM and disk space is so cheap. I’ll  get a bunch of sound designers, get them to make loops, load up my product with a thousand loops and plus I can now sell you extra ones. Why the hell would I be interested in Procedural Audio? There were two really powerful reasons – technical computer science reasons. Number one: If you haven’t got memory space like greeting cards, watches, mobile devices – one of the biggest errors of judgement in mobile/casual gaming and the whole mobile technology industry has been over estimating the available bandwidth. And what’s a good technology when you haven’t got any bandwidth? This is what is your biggest asset when you deliver procedural content. It occupies 4kb and plays for six hours. It has a million things that you can change all the time or download another one. So, as a technology procedural content is very powerful in situations where you’ve got limited bandwidth. With cars, another place where procedural technology is very powerful is where you want the sound to encode a large vector of changing parameters. Why is it useful to have a sound on a car? By listening to a car engine I can tell a lot about it – is it slowing down, speeding up, is it a large car or small car. I can localise it pretty well. So to replace a completely silent car engine what you want is a procedural sound object which behaves like the car (that is familiar to peoples expectations viz a viz reality – and hence safety) with engine, with tyre sounds, with exhaust simulation to delineate rear and front approach  In fact you could encode all kinds of other information about the car as a safety feature which people would quite quickly get used to. If it is a bus – it could be a bigger noise, if it is a bike it’s got a lighter sound. That would be difficult to do with a sample. So the procedural object would be more versatile and able to to encode more information. That would be argument number two. Argument number three might be that to develop a library of a thousand different car engines would be very expensive. But once Procedural Audio technologies mature I should be able to buy an engine model as a one piece of software and adapt it – I could commission it as a one of piece of software or buy it on a license, put in to my product and I have all the versatility of it. There comes a point I think where the code becomes cheaper than the recording, for a limited use case. Maybe. I’m not sure about the economics of that. I am interested to see how it turns out. If on the other hand there are a lot of people out there recording things and there is a very buoyant market in recordings….

DS: Do you see Procedural Audio code becoming a commodity that is built and sold?

Andy: I think so, I see that happening with the apps market. Production models have changed, and this is very much down to Apple. To their credit, I’m very anti-Apple at the moment (for ethical reasons), but to their credit one of the really good things that Apple has done is (by standardising experience and lowering expectations) accelerate the tool chain to the point where the production of an app is a half a day’s work sometimes. Cookie-cut template things that go out in the store and you download them. That is code. It’s the entire application. Whereas before, code was something that was produced over weeks or months, that still happens with bespoke apps but we’re seeing the trajectory towards commodity code like that. So yeah, if you are a great procedural sound designer why could you not be a guy who specialises in engines and you sold two to Volkswagen and one to Mercedes and you are working on a couple of other ones for some company? People come to you because they know you are the ‘engine guy’. Because its the standard API for interfacing with the procedural code you know at the end of the day you are going to get six floats or something – four rotational velocities for your wheels and you are going to get an engine speed and you are gonna get a bunch of stuff and you plug that in. I would like to be optimistic about the futures for these market places, I would like to think they they might work. That is very much my (humanist) philosophy as a person, I think that these things should create work which should create opportunities and they should create markets and they should create things that people can do and involve their talents and this is why I say you balance technology, art and business . And any one of those can become an overbearing dominant thing. The culture can override the technology and the business, the technology can become the “oh technology oh technology!” and stamp on the business but more often these days it’s about the business running out of control. If the business dictates the technology and the art, if any one of those three gets out to kill the other its bad. As for Apple, who want to commodify and control your creative experience for a profit motive – the absolute antithesis of their “nineteen eighty four position”. So what I would fear in the case that you are saying is that commercial attempts at pushing procedural audio initially turn out quite watered down,  neutered and over-packaged like supermarket food, in which case it will be procedural audio only in name, only in marketing speak. But then I’m a dreamer, 20 years ahead with this stuff in my head, disappointment with present reality is built in, its what keeps us pushing. Computational audio, more intelligent structuring of audio in games and cinema, will be a new creative frontier. But we need to get past a crisis of purpose with technology. The idea that easier is always better, that more is always better, dumbing down, disabling and concealing rather than opening up, enabling and enhancing. To paraphrase Laing who says “The emphasis is more and more on communication, but people have less and less to communicate”, we don’t really need more ways to do things, but better, more thoughtful and reflective ways to do things, to replace brute force and dizzying excess of choice from the previous epoch with more focussed and elegant ways. I hope some of the philosophies of procedural audio will shape sound design in a wider sense.

Set of 9 videos featuring sound designer Ben Burtt talking about sound and his work on “Super 8″.

The Recordist has released Ultimate Rockslide 2 HD Pro sound library, containing 750 24bit 96kHz rock and dirt sound effects on 115 Broadcast WAV files with detailed Metadata embedded.

This sequel to Ultimate Rockslide contains brand new rock based sound effects and multi-microphone files with tons of dirt and sand debris sounds recorded close up and distant to give the sound designer ample options. The multi-perspective files are also time aligned and grouped for easy access and auditioning. Most tracks contain many variations and performances for sound design flexibility.

Included in this collection are:
Large, medium and small rocks with tons of dirt debris – Gritty rocks off a cliff – Moist and dry dirt falling – Sand based debris sprays – Gravel dumped on wood boxes and platforms – Extended foley actions such as scraping, dropping, hitting, movement and much more.

Recorded with a set of extended frequency response microphones, the heavy weight and the subtle details of the rocks stand up to heavy layering and pitch manipulation This is the next generation of rockslides.

Available at $75.00 (1.20GB of sound).

Click here to view the embedded video.

‘Pugs Luv Beats‘ is a hilarious music composition game for iOS devices developed by Edinburgh based studio Lucky Frame. It’s about guiding pugs (in costumes) around a galaxy of worlds, whilst creating an endless variety of music. It sounds fantastic and runs on a generative sound/music engine developed in Pure Data.

Lucky Frame is Yann Seznec (artist, musician and sound designer), Jonathan Brodsky (artist, designer, musician, coder) and Sean McIlroy (illustrator and print maker). Jon and Yann were kind enough to make some time right after the release of the game to talk about the sounds and technology behind Pugs Luv Beats.

DS: How did Pugs Luv Beats come together?

Yann: Jon and I made an app called Mujik a couple of years ago. A lot of people downloaded it and there were a lot of good reviews. It was basically a different approach to music on a mobile interface. After playing around with that for a while we started thinking about how much further we could take the idea and Jon started getting into the idea of making games. So, we started thinking about how we could really bridge that gap between music and games. What if you could use a game interface to create music rather than to play music that is already there? That was the starting point. Jon made a demo which we dubbed ‘Space Hero’. The idea was that you were controlling a little ship that was shooting enemies. As the enemies came on screen they made a sound and as you destroyed them they made a sound, with the twist being you could edit how the enemies came after you so it was like a piano roll hybrid drum sequencer. It was more of a proof-of-concept than anything else. We took that to Channel 4 and to make a very long story short they ended up eventually telling us that they liked the idea and that they wanted to invest in it. Interestingly they told us, ‘We want to invest in the concept but don’t make that game’ [laughs]. So we started making various different prototypes for what became Pugs Luv Beats.

Click here to view the embedded video.

DS: What is Pug Luv Beats about?

Yann: We were just prototyping with lines and dots on the screen and I think we went through two full prototypes. We ended up with a little bug and you had to tell the bug where to go, and once it did it would create a sound and then you would have a second bug and you can tell that bug where to go and it would instantly start creating these interesting rhythmic loops. That was the core of the game. Once we had a fun-to-play instrument, we tried to figure out how to make a game out of it – which was quite a challenge. Eventually the bugs became pugs and we designed this whole crazy world around them and decided the sounds that they made would be dependent on what terrain they were on.

We then made a bunch of different terrains and terrain sound banks and each of them react slightly differently. We then had the idea of the pugs being slower on certain kind of terrains, and you can speed them up with costumes – if you want. If you don’t, then it means that they are slow. If they have a costume its going to be 25-50% faster which is really interesting because something that has a slow melody and rhythm will speed up.

The way we have it set up with ratios is quite cool because there are eight terrains and each of them has a slightly different ratio of ‘slower-ness’, which means you can get a ratio of 66% between two of the same distance and if it’s 4/3 or 5/4 or 7/4 you can get all these interesting rhythmic ratios going. The other level that we’ve added on top of it is that where the pugs are hitting are given a value. So as the pugs are running around generating all this music, they are raising your in-game currency and allowing you to explore other places and find new terrains and new costumes and new planets. I’ve just described the full game right there – Pugs Luv Beats.

Click here to view the embedded video.

DS: So it’s a generative music game which was designed in Pure Data? Why Pure Data?

Yann: That was a decision we made at the end of the prototype phase, it was almost too late.

Jon: LibPD (embeddable PD core) came out some time in 2010 and PD has been around for god knows how long. The embeddable core is so great for us.

Yann: It’s really amazing because before that we didn’t really have a proper way of doing sound at all.

Jon: I was writing the entire DSP engine and right before we got in to LibPD I had a chain-able DSP system that was defined through code. But, it wasn’t twenty years of audio research [laughs] that we could just drop in to our program.

Yann: I know very little code. Whereas, my training, if I can call it that, is in graphical programming with software like Max. I felt our time wasn’t being used effectively. As soon as we were able to integrate LibPD in to the whole system, it made our sound development strategy thousands and thousands of times better. Pure Data, being a brilliant and occasionally frustrating thing, was overall really good. The integration through LibPd and in to Objective C is surprisingly painless once its all setup.

Jon: A lot of people have done a lot of good work. The toolkit that we are using for running the game is called openFrameworks, which like Max or PD came out of the art and code movement. And a guy made a wrapper that takes the nice parts of LibPD and none of the nitty gritty things and it was probably less than a day’s worth of work to drop PD in to the game engine I had been building for a few months. LibPD itself was made by Peter Brinkmann with help from Peter Kirn. We have a lot to thank them both for.

DS: How is PD integrated with the game engine?

Jon: I basically send messages, just like how you would send messages in PD or Max/MSP between your different sub patches. I send those same messages from my game engine about what’s happening in the world in to LibPD. I construct lists that say, “There’s a bug on this tile, he’s picking up a beet and the BPM is whatever and the tile is this type”. There’s really not much integration, I can just tell PD what’s happening in the game at any point in time and then PD/sound designer deals with it.

Yann: Yeah, it literally was me making Pure Data patches as if I was making Pure Data patches for anything. The only difference being I have a little receive box in there that Jon is making the sends for and it outputs a giant list.

Jon: There’s one list for sound effects, there’s one for what happens in the world and there is one when the world is setup – I use a random number generator to generate the world.

Yann: It’s really great. It’s an amazing system. I get these three lists. The last list Jon described is the first thing that happens.

DS: So the world creation is completely random?

Jon: The nice thing about random numbers on computers is that they are totally predictable. The way random number generators work is that you give them a seed value and then every sequential random number is based on that seed value, so I don’t store the worlds, I just store seed values. When you go back to the world, I see the random number generator and regenerate the whole thing. That is also how we communicate about what world is on screen – just through those seed values.

Yann: We never even see that number.

DS: So it is a sort of identifier for the world?

Yann: That is exactly what it is. I use this number to do things, like pick a sound library for the beats.

DS: How many libraries does the game use?

Yann: At the moment there are only five. We may add some later on.

Jon: But that’s partially true. Only half of the sound engine is the beat sounds.

Yann: So beats are what happens when a Pug hits a beet [laughs]

Jon: The spelling of beats varies between vegetable beets and musical beats throughout the code. Sometimes the Pugs are still called rats for historical reasons [laughs]

Yann: Going through the code is hilarious! There are 5 beat libraries, which are each comprised of: a kick equivalent, a snare/clap equivalent and sound for when the beet is harvested. Otherwise there are libraries for each terrain as well. When it chooses a random number, it uses that random number to select which beat library it will use. It also sets a couple of other things – like there’s a little synthesiser you can play along with the planet. It will choose an attack and a decay on that synthesiser as well, that way each planet will have a lightly different sounding synthesiser. Another important thing that it does is it picks a scale or a mode (depending on how you want to think of it) and it applies that scale or mode to all the sound libraries and the synthesiser as well (the synthesiser is a semi-tuned synth). That way whenever you got to a planet it will be one of eight scales/modes. The way I’ve done that is for each library I have made a thirteen file sound-set for a chromatic scale, but that random number will select which look-up table it’s using and will select only eight of those thirteen. It does that across all the sound libraries. Another part of that list is the BPM. Each planet sounds quite different, even on a global level – in terms of being slower/faster, minor, mixolydian, major, etc.

DS: Is the BPM random?

Yann: The BPM for each planet is random, but will be the same when you return to that planet each time. Jon generates it from the random number, but sends it to me separately so its easier. I use that BPM not to trigger the sounds, because I’m getting the triggers from the code, but to calculate the delay times so that they are synced. I’ve put a soft delay on virtually everything to give a ‘rounder’ feeling. This whole process happens in a tenth of a second. Once you are on a planet, you have all these pugs running around. If you set a node and the pug starts running out, every time the pug jumps on to a new square I will get a list of numbers from Jon’s code. The list will be an identifier for the pug, what terrain he is on, whether he is wearing a hat, whether he is wearing a skin, whether the node he is jumping on is a node you placed or if he is just jumping on it to get to the node (I use that to make two different sounds).

Jon: It easier to think of the world as a heightmap rather than separate pieces of terrain. So there is actually an even more specific number. You can say, “this is sand, but also sand 0.5”, you can get a number between 0 and 1.

Yann: In practice that number is giving us a separate value for each terrain tile, which gives us a kind of location. If we have a specific number for each tile, every time a pug goes to that tile it plays the same sound.

Jon: It makes it like an instrument you can discover. It’s like a piano where you don’t know what note each key is going to play, but if you go back to that key it will play the same note.

DS: Each terrain has a different sound bank then?

Yann: Yes. I tried to match a vague conceptual thing to each sound bank. For example, the mountain is a kind of far off sounding synthesiser. The desert is an Iranian dulcimer called the Santoor, which is quite cool. For water I have an African harp. The links between the actual sounds and the terrain are somewhat tenuous but I was prioritising on making everything sound good. It can get quite chaotic when you randomly get a planet that has got five terrains – but that’s part of the fun.

DS: Were there many technical limitations in creating sound for such a game?

Yann: It limited me in the sense that I wasn’t expecting it. I was very used to patching on computers, so I had loads of buffers and then at one point Jon asked me, ‘How many buffers are you running?’. And, I was like, “There’s eight instances of that and there’s four buffers in each, so there’s thirty-two”, and he was like, “YOU HAVE THIRTY-TWO BUFFERS?!”, and that was just in one of the sections [laughs]. In PD doing polyphony is much more round about than in Max, so I did have to learn that kind of stuff. Artistically I didn’t feel very limited by it. What was really fun about setting up this patch was trying to make it as flexible as possible so that I could develop it further down the line. One of the updates for example might have pickups that change how the audio is played, so you can have the sound in reverse for or you could have the sound engine going all wonky at some point or the other.

DS: Considering you can do anything you want, do you set up artistic limitations for yourself?

Yann: It’s really hard. I think for us the biggest advantage in forcing us to be limited is we have a real goal in mind – a released commercial piece of mobile gaming software. That’s a real interesting framework to try to place around everything. You could use the same data from this game and each formant of a sound can be applied to each pug and you can do crazy harmonic re-synthesis stuff. It would be awesome! Very cool! Who would want to play that? [laughs]

Jon: I think to a certain extent you are limited by time and complexity. There are a lot of defaults happening. The art style is very much like what’s in Sean’s sketchbooks. The African harp and Iranian dulcimer, that’s the most default Yann sample-set [laughs].

DS: What about the choice of sounds, considering it’s for iOS devices?

Yann: We made two choices very early on from a sound design perspective. One being we didn’t want to rely on people wearing headphones. Whilst I of course wish that everybody played all music games with headphones, I think it is unreasonable.

Jon: Or more preferably with studio monitors [laughs]

Yann: Yeah! “Please use medium field speakers with proper sound insulation” [laughs]. We decided very early on to make it sound awesome through headphones and awesome through the built in iphone speakers. It is a challenge. What it means is that you have to have mid-range in all your sounds and you need to make that mid-range not sound annoying when you listen on headphones. Stuff like the santoor cuts right through. And when you are dealing with generative sound like this you have to be careful about volumes. We haven’t put a compressor on anything, I haven’t really felt the need for one yet. The big sounds like bass drums were quite tricky, but it’s about putting a peak at the mid/high range to make stuff cut through.

DS: Considering most of the sounds occupy the mid-range, did you also try to create contrast between them?

Yann: The beats, the vegetable beets that create beats are the main percussive element. Otherwise I wanted to have a bit of a range. There’s a kind of a distortion guitar thing, there’s a sine wave synthesiser, there’s the santoor, there’s a xylophone/toy piano.. they need to be cohesive but also different enough so that when you land on new terrain it is really clear that a new sound is happening. It was quite challenging to make it sound like you were in the same game still. Also, everything runs at 22k but it does sound good and it’s funny how you much can get away with at 22k. It’s still in stereo.

DS: You mentioned about updates to the game. Anything around the corner?

Yann: Yes indeed! We are currently working on our next release, which is going to be a free app that is just the synthesizer part of Pugs Luv Beats, developed slightly to allow you to dress up the pugs in outfits and hats to create different synth voices. People really love playing with the singing pugs so we figured it would be a fun spinoff. That will be released in a couple of weeks.

Shortly afterwards we’re also going to release another update to Pugs Luv Beats to tweak a few things like the in-game beat currency. We’ve gotten some really great feedback on some small changes to make, so we’re going to implement a bunch of those.

After that we’re going to make a different music game entirely, but that’s all still hush hush!

DS: Pugs Luv Beats just got nominated for an IGF award for ‘Excellence in Sound’. Excited?

Yann: We are super excited! It’s absolutely amazing news for us. The other nominees are of such a high quality, it’s incredible to be associated with them. It’s particularly great to be recognised for the audio, since it is a music game and all.

http://luckyframe.co.uk
Twitter: @lucky_frame
The Amazing Rolo
More information on Pugs Luv Beats and LibPD integration on the CDM blog

First: a BIG thank you to all the contributors, this wouldn’t have been possible without the sounds!

How did this work?

The Max/MSP patch works by playing random files in a random sequence and from random points within the files. If left by itself it can play these files back in this random order to create a never-ending soundscape. Although, there are a few controls to help design the way it sounds:

• Play length of each file (Eg.: If it’s set at 4000ms, it would play back a sound for 4000ms and then crossfade into the next sound)
• Fade length – crossfade length (from 0ms to 1ms less than the play length)
• Speed/pitch: Vari-speed playback control
• Reverse
• Random type: Urn (random without repeats), Drunk (Randomised but ‘drunken’), Random (random with unpredictable repeats), Counter (sequential playback)

The outputs were connected to a channel strip type interface, from which the signal was sent (parallel) to a reverb and delay plugin.

What you hear below are sounds that were contributed (thank you again!) and then generated and ‘performed’ using the above mentioned controls with a MIDI controller. I recorded a few takes and this was the one I preferred the most. I’ve also included a screengrab of the patch at work, for the curious.

Have a great sounding year ahead!

Thanks to:
Eckhard Kuchenbecker
Echo Collective
Hrishikesh Dani
Chris Nealy
Angel Perez Grandi
Jaydea Lopez
Ana Roman
Péter Terner
Anna Papaioannou

Year End Sonic-Mash on Soundcloud

Click here to view the embedded video.