[PD] Comments on pd as a library to be used in game

[Andy Farnell]

Hello Pablo, list,


Let's differentiate two issues,


1) To use Pd as a sample replay based game audio engine
2) To use Pd as a procedural audio engine (synthesis).

These are different tasks with different goals and challenges. The latter is my
domain of expertise and something, for me;

i) Very optimistic and enthusiastic about.
ii) Aware that it is still ambitious and difficult.
iii) Have though about many of the problems and how to do it. (and prepared to lead
a team who want to do this)


The former is also very exciting, and would yield wonderful benefits. It may 
in fact be a necessary stage to get to doing realtime synthetic game audio
through Pd. Maybe we should focus on that first.

But, if I were leading the audio team right now I would be quite wary of doing
this in such a bold way as to say we will rely 100% on Pd, from an entirely
practical, realistic POV. I only say this from my experience with mod teams
and the practicalities of switching technology mid stream, that's why i sound
cautious.

However, we should start this... even if it doesn't get used this cycle, maybe
with a fallback position of using the CS audio engine and doing content in Pd?

Creating a project that brings together CS, Blender and Pd is awesome!

FWIW I can;

1) Donate some existing models or patches 
2) Work as "procedural sound designer" to create sound objects.
3) Help out the team by guiding others to do this.
4) Be a regular sound designer and create static content using Pd for the game.


My opinion about the challenges

Before Pd can be a truly good candidate for the job it must solve these issues.
None of this means Pd can't be used right now with some hacking, but this is 
where the Pd-Games project should be headed...Some of these are easy, some are 
hard, some are being worked on, some are just dreams...

i) Dynamic DSP graph reconfiguration. The ability to seamlessly (no clicks or 
dropouts) create and destroy graph elements and garbage collect on the fly.

ii) Through a supported (official and documented) message passing system

iii) Intermediate object manager layer (Python?) (as suggested Pd objects) to
create, coordinate, destroy sound objects.

vi) Some properly optimised reverb and spacialisation (5.1 etc) objs (as C externs)


2) Link in as a library with

i) The interpreter/scheduler
ii) A solid, complete set of standard opcodes.
iii) Threadable subgraphs for (good enough - not optimal/perfect) parallelism
vi) Cost prediction/resource capping etc (so the Pd engine can't kill the machine
if someone tries to spawn 1000 expensive sounds)

OTOH, if Pd is to be run as a separate process we must be able to terminate it and/or
bring it back reliably.


"Nova" and "Desiredata" both have made progress with some of these. Plus there are 
successful external (not Pd) projects we can look to for inspiration.


When is the next meeting of the Apricot sound team?

best wishes,

Andy

On Mon, 11 Feb 2008 15:55:45 +0100
Pablo Martin <caedes at sindominio.net> wrote:

> Andy Farnell escribió:
> > Hey Pablo,
> >
> > Yes it is feasible. So Apricot is to use Pd?
> >   
> 
> Well its still being decided, and most team know nothing about pd, so
> they are a bit reluctant to accept this kind of risks... though they
> also understand some of the good parts, but of course i think it would
> be great.
> 
>  Pablo
> 


-- 
Use the source