Conditional gate
@mod said:
But time and time again we see the same sort of posts. People who just want to turn an audio signal on and off use something like [spigot~], people use [counter] instead of basic pd objects. They post these patches and run into trouble that could easily be avoided by only using vanilla objects unless necessary.
What's wrong with [counter]? Objects like those remedy the trouble of trying to figure out how to make one using only vanilla objects. Not that it's particularly difficult to do, but it may just be more intuitive or time saving to someone to use [counter].
Of course most people are using extended, but it's such a vast ocean that no-one knows how EVERY object in extended works. The object in question here, [gate], i can only hazard a guess, but i'm thinking that a maximum of 50% of users know the cyclone library and in particular the [gate] object well enough to debug a patch.
Well, that's where the basic advice that you and others have posted comes in: Right click -> Help.
Besides, I don't really think that because less people know or use an object should deter one from trying it. It may just make more sense or fit with their particular programming preferences. I know I like to build from low-level objects and work up, but not everyone is so interested. For example, I've built my own compressor abstraction. But plenty of other people would rather just load a compressor object and be done with it. Nothing wrong with either approach.
Also, I've been using Pd long enough that I feel comfortable saying I'm in "expert" territory. I don't know what every extended object does, but I don't know what EVERY vanilla object does, either.
(I'm speaking from my own bad experiences here too, because my old patches had some extended objects in them, and i answered countless emails from people having trouble with those externals not loading. I could have saved myself a lot of time by just using the correct vanilla constructs in the first place)
Now, this is a different issue, and I'm more inclined to agree here. You can definitely ensure higher compatibility by sticking to vanilla objects, as some externals don't work correctly on all OS's and vanilla users may not have some of the more popular libraries installed, but it does come with the potential costs of flexibility or computational load. And, this is only an issue if you want to share your patches or use them on other OS's.
When I'm writing a patch that's for personal use only, and I don't expect to be sharing it, I tend to use whatever I want. But if I'm making an abstraction I might share, I usually follow an order of precedence:
1. Use vanilla objects where possible/practical for best compatibility.
2. Use extended objects if needed, since it's used widely and newbie-friendly.
3. If absolutely necessary, use a popular lib not included in Pd-extended, like GridFlow or RjLib (I've never had to do this, yet).
But that's entirely for compatibility reasons only.
@Shakasin said:
But is there something in vanilla that could replace my [gate] just curious ?
. [== 1] [== 2] [== 3]
| | |
[spigot] [spigot] [spigot] etc....
Connect the gate number to the left inlet of the [== ] objects, and the value you want to pass to the left inlet of the [spigot]s.
Arduino, ultrasonics and Pd: HELP needed for degree project!
Dear Pd'ers… I'm fairly new to Pd and have been using it during my 'Audio Production' degree at SAE college in London. I'm here to ask for help on my final degree project, which aims to control objects within Pd by way of proximity sensors connected to Arduino.
I have had moderate success, first using a Sharp GPD12 IR sensor connected to an analog port on an Arduino Diecimila, then a Devantech SRF02 connected via I2C to Arduino. I have managed to get Pure Data reading the sensor values using the Pure Data example included in SimpleMessageSystem (http://www.arduino.cc/playground/uploads/Code/SimpleMessageSystem.zip)... and only altering the number of the comport the Arduino appears on.
On the Arduino end, I have added the SimpleMessageSystem library, and am using the following sketch to run one or both of the sensors depending on whether or not I omit the SRF02 or GPD12 parts of the code.
// top //
#include <Wire.h>
#include <Servo.h>
#include <SimpleMessageSystem.h>
int sensorPin = 0;
int sensorValue = 0;
Servo servo1;
#define sensorAddress 0x70
#define readInches 0x50
#define readCentimeters 0x51
#define readMicroseconds 0x52
#define resultRegister 0x02
void setup()
{
Wire.begin();
Serial.begin(9600);
}
void sendCommand (int address, int command) {
Wire.beginTransmission(address);
Wire.send(0x00);
Wire.send(command);
Wire.endTransmission();
}
void setRegister(int address, int thisRegister) {
Wire.beginTransmission(address);
Wire.send(thisRegister);
Wire.endTransmission();
}
int readData(int address, int numBytes) {
int result = 0;
Wire.requestFrom(address, numBytes);
while (Wire.available() < 2 );{
}
result = Wire.receive() * 256;
result = result + Wire.receive();
return result;
}
void loop()
{
// SRF02 READING //
sendCommand(sensorAddress, readInches);
delay(70);
setRegister(sensorAddress, resultRegister);
int sensorReading = readData(sensorAddress, 2);
Serial.println(sensorReading);
delay (200);
// GPD12 READING //
sensorValue = analogRead(sensorPin);
int range = (6787 / sensorValue);
Serial.println(range);
delay(200);
}
// bottom //
Pure data is picking up the sensor's output as a decimal number, through the serial port, correctly, and showing this as a number in the SPECIAL CHARACTER section of the Pd patch, which I can then use to control various Pd parameters, like a slider for example.
If printing both sensor readings to the serial, the Pd patch will pick up the two sensor values alternately, but there seems no way of differentiating the two sensors within Pd, as they both come through the serial. I have tried prepending the serial print at the Arduino stage with a tag such as "IR" or "UL" for each sensor, but this simply ends up in nothing coming through in Pd.
Using one sensor gives the ability to control parameters with a fairly narrow detection range, but for the final version I would like to incorporate 4 or 5 sensors in order that I can cover nearly a full 360 degree range.
After a bit of research I have gone and bought 4 x Maxsonar EZ0's. They've got a wider range than the Devantech sensors, and can operate via I2C, serial or PWM. A number of people online seem to mention the improved stability when operating via PWM, so I thought this could be kinda useful.
I am going to London Hackspace tomorrow to get help with wiring up the sensors to my Arduino Diecimila, but for now, my main problem seems to be how to achieve greater communication between Pure Data and the sensors. It's all very good and well being able to take the decimal readout from an analog input to give one set of values in Pd, but I would like to know how to either to read (and trigger) each sensor discretely via PWM, or to somehow differentiate between each sensor's analog output, so that I can have the different sensors controlling different objects within Pd.
As well as SimpleMessageSystem, I looked at using the Pduino object. But to be honest, it is either not working properly (I have noticed reported issues with bugginess), or I am being stupid, as it has totally boggled my brain. In theory though, it seems like it should be able to do what I want, ie. send and receive commands between Arduino and Pd.
****************************************
So…. my questions for anyone out there with a knowledge of using Arduino + multiple sensors (preferably Maxsonar EZ's) with Pd are:
What is most appropriate for my project?
- Simple Message System or Pduino?
- analog or PWM?
And how do I get proper communication between the two platforms so I can discern discrete values from each sensor?
I'd really like to get a discussion going with this as (a) it would really help me in my degree (which ends in about 4 weeks!!!) and (b) I really want to share what I am doing, especially as the discussions on Arduino/Pd communication on the various forums seem a little patchy (at least for noobs like me). I also hope to continue my research in the future, sharing any findings I make with the community…
****************************************
PS. In the sharing spirit, please check out the Radio Tuner patch I've just posted over on the patch section of this forum - it's my first successful attempt at Pd... I hope you enjoy
Bandlimited oscillators
This is a collection of abstractions that generate bandlimited oscillators. They include:
[bl-saw.mmb~] - bandlimited sawtooth waveform
[bl-pulse.mmb~] - bandlimited pulse wave with PWM
[bl-tri.mmb~] - bandlimited triangle wave
[bl-asymtri.mmb~] - bandlimited asymmetrical triangle wave (sort of...see below)
There is also an object called [bl-init.mmb]. This is the object that initializes all the waveforms and at least one instance MUST be included in order for the others to work.
There are also help patches included.
IMPORTANT!
Before you can use these, you must do the following steps.
1. Open [bl-init.mmb]
2. There is a message box that says [44100(. This is the maximum sampling rate that these will work at (running at lower sampling rates will be fine). If you plan on using higher sampling rates, change this message box and click it. Technically, it will still work at a higher sampling rate, but it won't generate harmonics above the sampling rate in this box.
3. Click the [bang( to fill the wave tables. This patch actually creates a wavetable for EVERY harmonic between 30Hz and the Nyquist frequency. So it will take a few minutes. Be patient! You will get a message in the Pd window when it is done.
4. Save the patch.
Once you do this, [bl-init.mmb] will simply load with the tables already generated, so you don't have to wait every time you instantiate it. I didn't have this already done for you in order to keep the upload small, and so you can see how to adjust it if you need to.
So, I guess I'll go ahead and try to explain how these work. As stated above, every harmonic is generated in [bl-init.mmb] for the oscillators. It doesn't create a table for each set of harmonics however (e.g., there isn't a saw table with two harmonics, a saw table with three harmonics, etc.). Instead, each of these individual tables are tacked on to the end of each other to create one long wave table. So, for each set of 1027 samples in the sawtooth wavetable, there is one cycle with a set amount of harmonics.
When the oscillators read the frequency input, it is divided into the Nyquist frequency to determine how many harmonics are needed. It then uses this (* 1027) as the offset for the table. This is how I got around the problem of table switching at block boundaries. By doing this way, the "switching" is done at audio rate.
There are actually two [tabread4~]s. One has one less harmonic than the other. As the frequency changes it crossfades between these tables. When one table goes completely silent, that's when it "switches." Below 30Hz, they switch to geometrically perfect waveforms.
[bl-saw.mmb~] and [bl-tri.mmb~] just read through the tables. Nothing really interesting about them.
[bl-pulse.mmb~] is actually the difference between to sawtooths. In other words, there are two bandlimited sawtooth oscillators inside of it. Adjusting the pulse width cause the phase of one of the sawtooths to shift. When you subtract this phase-shifted sawtooth from the other, it creates a bandlimited pulse wave...without oversampling! This is the same Phase Offset Modulation method used in Reason's SubTractor.
[bl-asymtri.mmb~] uses the same technique as [bl-pulse.mmb~], except it uses bandlimited parabola waves instead of sawtooths. Adjust the phase offset sets where the top vertex is. This doesn't really generate true triangle or saw waves, though. They still have the parabolic curve in them, so the harmonics seem to come out a little more. It's more of a "reasonable approximation." But, it is bandlimited, and it does sound pretty cool to modulate the shape. I don't have the scaling quite right yet, but I'll get to it later...maybe.
I should also mention that these use my [vphasor.mmb~] abstraction, so the phase reset is sample accurate.
I'll eventually set these up to allow frequency and pulse-width arguments, but I'm currently in the process of moving to another country, so it may be a little bit before I get around to it.
Didn't any of that make any sense?
Building a modular synth
I'm not sure I entirely understand your first question. Why exactly would plugin support help your modular design in Pd?
As for routing audio, I use jackOSX with Pd all the time. Here's how it works for me:
- Open JackPilot.
- In the preferences, set your buffer size and such to your liking. The virtual ins and outs are important. These are the number of connections that will be allocated to each app.
- Start the server.
- Open Pd and, under the media menu, select jack mode. This will open the audio setting dialog with jack set as the input and output device. Adjust the channels to whatever you need.
- Open whatever other app you're using and set the input and output devices to jack server or whatever it says.
- Now, go back to JackPilot and click the Routing button. In the send ports (which are your apps' outputs) unfold Pd's and select and output. Under receive ports, unfold the other app and double click the input you want to connect to. Or vice versa if you're feeding into Pd. Also, make sure that you're routing the app with the mixed signal (probably the DAW, if you're using that) to the sound card's inputs. This is always labeled "system."
Yes, there will always be latency, but on OSX it seems to be minimized with jack. Even if you're using Pd on its own, you can get lower latency if you route through jack and then into the sound card. You will get added latency every time you go in and out, so try to minimize that. And multiple cores won't make a difference if you're only using Pd, as it will only run on a single core. If you're using other apps, then it might help as they may run on a different core than Pd.
As for the standardization, I know there are some who would like to see everything scaled in a 0-1 range. But I don't think it's that big of a deal in Pd when it comes to sharing patches, as Pd gives you what you need to convert ranges if you need to. I would just go with what works best for your particular needs. Sometimes standards set by others can get in the way.
If you haven't yet, check out hardoff's DIY2 library. It might give you some ideas.
http://puredata.hurleur.com/sujet-1982-diy2-effects-sample-players-synths-sound-synthesis
Hope that answers some of your questions.
Pd/rjdj skillshare @ Eyebeam, NYC, Dec 5th
http://eyebeam.org/events/rjdj-skillshare
December 5, 2009
12:00 -- 1:30 PM : Introductory workshop on Pd with Hans-Christoph Steiner
2:00 -- 6:00 PM : SkillShare w/Steiner and members of RjDj programming team
Free, capacity for up to 30 participants
RSVP HERE: http://tinyurl.com/ykaq3l3
Hans-Christoph Steiner returns to Eyebeam with members of the RjDj programming team from Europe to help turn your iPhone or iPod-Touch into a programmable, generative, and interactive sound-processor! Create a variable echo, whose timing varies according to the phone's tilt-sensor or an audio synthesizer that responds to your gestures, accelerations and touches. Abuse the extensive sound capabilities of the Pure Data programming language to blend generative music, audio analysis, and synthy goodness. If you're familiar with the awesome RjDj, then you already know the possibilities of Pure Data on the iPhone or iPod Touch (2nd and 3rd generation Touch only).
Creating and uploading your own sound-processing and sound-generating patches can be as easy as copying a text file to your device! In this 4-hour hands-on SkillShare, interactive sound whiz and Pure Data developer Hans-Christoph Steiner and several of the original RjDj programers will lead you through all the steps necessary to turn your phone into a pocket synth.
How Eyebeam SkillShares work
Eyebeam's SkillShares are Peer-to-Peer working/learning sessions that provide an informal context to develop new skills alongside leading developers and artists. They are for all levels and start with an introduction and overview of the topic, after which participants with similar projects or skill levels break off into small groups to work on their project while getting feedback and additional instruction and ideas from their group. It's a great way to level-up your skills and meet like-minded people. This SkillShare is especially well-suited for electronic musicians and other people who have experience programming sound. Some knowledge of sound analysis and synthesis techniques will go a long way.
We'll also take a lunch break in the afternoon including a special informal meeting about how to jailbreak your iPhone!
Your Skill Level
All levels of skill are OK as long as you have done something with Pd or Max/MSP before. If you consider yourself a beginner It would help a lot to run through the Pd audio tutorials before attending.
NOTE: On the day of the SkillShare we will hold an introductory workshop from 12:00 until 1:30 PM, led by Steiner, for those who want to make sure they're up-to-speed before the actual SkillShare starts at 2:00. The introductory workshop is for people who have some done something in Pd or Max/MSP but are still relative beginners in the area of electronic sound programming.
What You Should Bring
You'll need to bring your iPhone or iPod Touch (2nd or 3rd generation Touch only), your own laptop, a headset with a built-in mic (especially if using an iPod Touch) and the data cable you use to connect your device to your laptop. Owing to a terrific hack, you won't even need an Apple Developer License for your device!
More Information
RjDj is an augmented reality app that uses the power of the new generation personal music players like iPhone and iPod Touch to create mind blowing hearing sensations. The RjDj app makes a number of downloadable scenes from different artists available as well as the opportunity to make your own and share them with other users. RjDj.me
Pd (aka Pure Data) is a real-time graphical programming environment for audio, video, and graphical processing. Pd is free software, and works on multiple platforms, and therefore is quite portable; versions exist for Win32, IRIX, GNU/Linux, BSD, and MacOS X running on anything from a PocketPC to an old Mac to a brand new PC. Recent developments include a system of abstractions for building performance environments, and a library of objects for physical modeling for sound synthesis.
kill your television
"Morphine" - fx-morphing engine
for some reason, the list of error messages became even longer......
mix.switch.nice 101
... couldn't create
init.post.dollarg
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
flow.receive
... couldn't create
[makesymbol] part of zexy-2.2.3 (compiled: Feb 25 2009)
Copyright (l) 1999-2008 IOhannes m zmölnig, forum::für::umläute & IEM
flow.@parse
... couldn't create
flow.receive
... couldn't create
init.dollar.zero.top
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
list.build
... couldn't create
[demultiplex] part of zexy-2.2.3 (compiled: Feb 25 2009)
Copyright (l) 1999-2008 IOhannes m zmölnig, forum::für::umläute & IEM
init.make.unique
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
list.split 1
... couldn't create
list.length
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
wahwah~: an audio wahwah, version 0.1 (ydegoyon@free.fr)
expr, expr~, fexpr~ version 0.4 under GNU General Public License
mix.switch.nice 101
... couldn't create
init.post.dollarg
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
flow.receive
... couldn't create
flow.@parse
... couldn't create
flow.receive
... couldn't create
init.dollar.zero.top
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
list.build
... couldn't create
init.make.unique
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
list.split 1
... couldn't create
list.length
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
mix.switch.nice 101
... couldn't create
init.post.dollarg
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
flow.receive
... couldn't create
flow.@parse
... couldn't create
flow.receive
... couldn't create
init.dollar.zero.top
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
list.build
... couldn't create
init.make.unique
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
list.split 1
... couldn't create
list.length
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
mix.switch.nice 101
... couldn't create
init.post.dollarg
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
flow.receive
... couldn't create
flow.@parse
... couldn't create
flow.receive
... couldn't create
init.dollar.zero.top
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
list.build
... couldn't create
init.make.unique
... couldn't create
flow.receive
... couldn't create
flow.receive
... couldn't create
flow.send
... couldn't create
list.split 1
... couldn't create
list.split 1
... couldn't create
list.length
... couldn't create
flow.send
... couldn't create
flow.send
... couldn't create
error: inlet: expected '' but got 'symbol'
... you might be able to track this down from the Find menu.
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'symbol'
error: inlet: expected '' but got 'list'
i'd really love to check out, what you have build there!
Wanted: pure pd sounds / tracks / patches
details:
'pure data' means pure data vanilla or pure data extended. it excludes the use of any other sound processing application to make or sequence sounds, and excludes the use of VST, ladspa, audio unit etc plugins within pure data itself. triggering and controlling sounds with external hardware such as midi knobs and faders, arduino, etc, is totally fine. using an audio editor to record and do simple edits (crop, normalize, etc) of pd material is also fine, as long as the sound is not resequenced and no effects are added.
basically the sound needs to start and end in pd. this doesn't mean it all has to happen realtime. i have been having lots of fun lately with running sampled pd sounds through various sampling devices and effects)
my goal at the moment is to make some 'sample packs' of pure pd sounds which i will then release here and in other places under the creative commons license, so any submissions would need to be covered by an equally free agreement.
after that, what i do with those samples, and what anyone else does with those samples is up to us, and would be covered by creative commons. my final goal is to make an album worth of music and sounds using only pure data,
i can be contacted by email at hard.off@gmail.com
Transdetect~ and transcomp~: transient shaping and detection
transcomp~ uses transdetect~ to shape the initial attack and release of a signal.
Requires IEM's FIR~, fexpr~ and dbtorms~ which are provided in PD-Extended.
To work properly the transdetect folder should be added to PD's path.
Start by opening help-transcomp~.pd
01 Implementation:
transdetect~ works by using two pairs of envelope followers. The first pair
subtracts an envelope follower with a slow attack from an accurate follower,
the result of which is a signal containing the initial attack. For the initial
release, the second pair subtracts an accurate envelope follower from one with
a slow release.
An envelope follower measures the mean square power of a signal over time
(see 3.audio.examples/H06.envelope.follower.pd for details on implementing an
envelope follower). To do this we must use a low pass filter at a very low
frequency. In order to achieve an accurate follower a linear phase FIR filter
was used (using IEM's FIR~ external). Unfortunately this introduces a phase
delay.
In order to facilitate the use of different envelope follower implementations,
transdetect~ requires a filter type as a creation argument implemented in
followernameTransDetectEF~.pd. 4 linear phase fir implementations are provided:
181, 251, 451 and 501 taps filters. The 501 taps filter provides the most
accurate filter but with a phase delay of 5.668 ms at 44.1kHz (raise the
sampling rate to lower the phase delay). They were all generating using
http://www.dsptutor.freeuk.com/FIRFilterDesign/FIRFiltDes102.html with a
cutoff frequency between 5 and 10 Hz.
A compromise between accuracy and phase delay might be achieved by using
minimum phase FIR filters. A 5th implementation using PD's native lop~ object
is also provided under the designation iir (FIR~ not required).
Along with different possible envelope follower implementation transdetect~
also requires an attack and hold type implemented in
attacknameTransDetectAttackShape~.pd and holdnameTransDetectHoldShape~.pd
respectively. These implementations dictate the kind of attack and release
curves used on the envelope followers (linear, slow[er|est] and fast[er|est]).
All implementations provided use fexpr~. A more efficient external could be
made to take fexpr~ place.
02 Use
In help-transcomp~.pd patch enable start and pay attention to the snap in the
hit. Disable the green toggle button to disable the compression make the snap
go away. Check out the tables on the left to see the results of the transient
compression.
transcomp~ is useful when used with recorded drums to maximize or minimize
its transient (to make it punchier or to make snare drums less clappy).
transcomp~ uses transdetect~. By itself transdetect~ can be used to synthesis
hits from a recording. For example, take a bass drum recording and use the
signals generated by transdetect~ to shape the frequency and envelope of a
synthesized kick drum.
Would love to have some feedback and some help in turning the linear phase filters into minimum phase filters.
Crack
> 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...
a.
Crack
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...)
http://obiwannabe.co.uk/sounds/effect-jetengine.mp3
http://obiwannabe.co.uk/sounds/effect-three-synthetic-jets-flypast.mp3
http://obiwannabe.co.uk/sounds/effect-singleprop-cockpit.mp3