"...Pure Data, the 'crack cocaine' of multimedia software..."
Remember, drugs are for losers mmmkay, don't rob yourself.
But Pd... hmmm, it's got vitamins in it.
Use the Source.
Until today no. Thanks for the pointr, Obarski is obviously a legend. Perhaps the Empire were onto him and he had to retire to a desert moon. Well, I hope our paths will cross, I wonder what he would make of Pd for real-time synthesised game music? I think i've described trackers as a "lost" format before. There's (at least one) conspicuous discontinuity of development in game audio. But the promising news from 2007 that bodes well for this year and beyond, Sony and EA both embedding Pd as the next generation procedural audio engine. Pd may become the standard interactive sound description language.
Use the Source.
Sony and EA both embedding Pd as the next generation procedural audio engine. Pd may become the standard interactive sound description language.
What? How so? Does this mean it may be possible to have a private sector job doing PD someday?!
Yep. Things are going that way. Making it a standard is just my wishful vision! Not everyone is going to settle on Pd. There are other dataflow type interfaces to different unit generator sets like CPS, but there's a distinct movement in the direction of dataflow as a method for building procedural audio code...as it should be I started to advocate this years ago as many here know, but found out only recently that EA have indeed ported Pd into some games, mainly for generative music scoring. Sony have something in R&D for the PS3 and certain game audio engine manufacturers have certainly considered it. I continue to knock on their doors, thump my bible and try to convince them to accept the good news into their hearts It would be wonderful to establish Pd as the main audio component in games for runtime production because it's the correct tool to break down the barrier between sound designer and audio programmer, that's the way to push things forwards.
If you want to support this direction, the title to run out and buy is Spore. Brian Eno and others wrote procedural music scores using a cut down version called EAPd, which Mark Danks (GEM author, now at Sony) led the charge to embed as the audio engine.
More than one chapter of the book I'm working on is devoted to designing patches for game applications, how to do dynamic level of detail and interface to event streams from world controllers and physics engines.
I'd say dataflow programmers, whether audio or visual, have a good future ahead for commercial employment (but then I'm (very) biased
Here's some types of things in dev, these are components for planes, sort of thing you'd use in air combat games or whatever.
One of them is developed as a practical example in the book. (I'm trying to get an accurate Supermarine Spitfire working at the moment...)
Use the Source.
Andy, *astonishing* sounds.
100% Pure Pure Pure PureData?
(allowed answers: YES!!!).
Very nice discussion indeed. Stimulating and exciting.
For sure audio in videogames had not gained so much in development as the graphic counterpart,
but maybe times are mature now for putting togheter the low-level and mid-level parts like Sony is doing
right now with Spore..
> Sony and EA both embedding Pd as the next generation procedural audio engine
About EA: which games?
>It would be wonderful to establish Pd as the main audio component in games for runtime production because it's the correct tool to break down the barrier between sound designer and audio programmer, that's the way to push things forwards.
So this means designing an audio engine which is both responsive to the soundtrack/score, as well as to the actual action and human input of the game? Why wouldn't PD be the natural choice?
Obi, I've noticed that a lot of your tutorials and patches are based on generative synthesis/modelling, rather than samples. Is this the standard in the game world? Is this cheifly to save space on the media? Cpu cycles? Or is it simply esier to create non-linear sound design this way?
> Andy, *astonishing* sounds.
> 100% Pure Pure Pure PureData?
> (allowed answers: YES!!!).
Thanks very much Alberto, as you surmise...yes indeed. Not just pure Pd but very efficient Pd. One tries to re-factor the equations and models, transforming between methods and looking for shortcuts, boiling each one down to the least number of operations. There are nicer sounds, but these ones are developed to use low CPU and run multiple instances in real-time.
> About EA: which games?
Truth be told, I don't know. If I did I would probably have to observe NDA anyway. Which is one reason I'm not working on them, because I am going to publish all my methods in a coherent and structured thesis - it's the best strategy to push procedural audio forwards for all. Maybe it will be personally rewarding later down the line. But I do talk to leading developers and R&D people, and slowly working towards a strategic consensus. All the same, I'd be rather cautious about saying who is doing what, games people like to keep a few surprises back
> So this means designing an audio engine which is
> both responsive to the soundtrack/score, as well as
> to the actual action and human input of the game?
> Why wouldn't PD be the natural choice?
Pd _would_ be the natural choice. Not least of all, it's BSD type license means developers can just embed it. But it has competitors, (far less capable ones imho) that have established interests in the game audio engine market including a vast investment of skills (game sound designers are already familiar with them). So rather than let Pd simply blow them out of the water one needs a more inclusive approach by saying "hey guys..you should be embedding Pd into your engines"
Many hard decisions are not technical, but practical. For example you can't just replace all sample based assets, and you need to plan and build toolchains that fit into existing practices. Games development is big team stuff, so Pd type procedural audio has to be phased in quite carefully. Also, we want to avoid hype. The media have a talent for siezing on any new technological development and distorting it to raise unrealistic expectations. They call it "marketing", but it's another word for uninformed bullshit. This would be damaging to procedural audio if the marketers hyped up a new title as "revolutionary synthetic sound" and everyone reviewed it as rubbish. So the trick is to stealthily sneak it in under the media radar - the best we can hope for with procedural audio to begin with is that nobody really notices Then the power will be revealed.
> Obi, I've noticed that a lot of your tutorials and
> patches are based on generative synthesis/modelling,
> rather than samples. Is this the standard in the game world?
No. The standard is still very much sample based, which is the crux of the whole agenda. Sample based game audio is extremely limited from an interactive POV, even where you use hybrid granular methods. My inspiration and master, a real Jedi who laid the foundations for this project is a guy called Perry Cook, he's the one who wrote the first book on procedural audio, but it
was too ahead of the curve. Now we have multi-core CPU's there's actually a glut of cycles and execs running around saying "What are we going to use all this technology for?". The trick in moving from Perrys models to practical synthetic game audio is all about parameterisation, hooking the equations into the physics of the situation. A chap called Kees van den Doel did quite a lot of the groundwork that inspired me to take a mixed spectral/physical approach to parameterisation. This is how I break down a model and reconstruct it piecewise.
> Is this chiefly to save space on the media?
Not the main reason. But it does offer a space efficiency of many orders of magnitude!!!! Just as a bonus I don't think many games developers have realised or understood this profound fact. Procedural methods _have_ been used in gaming, for example Elite was made possible by tricks that came from the demo scene to create generative worlds, and this has been extended in Spore. But you have to remember that storage is also getting cheaper, so going in the other direction you have titles like Heavenly Sword that use 10GB of raw audio data. The problem with this approach is that it forces the gameplay to take a linear narrative, they become pseudo-films, not games.
> Cpu cycles?
No, the opposite. You trade off space for cycles. It is much much more CPU intensive than playing back samples.
> Or is it simply easier to create non-linear sound design
> this way?
Yes. In a way, it's the only way to create true non-linear (in the media sense) sound design. Everything else is a script over a matrix of pre-determined possibilities.
oops rambled again... back to it...
Use the Source.
Oops! Looks like something went wrong!