Hello Pablo, list,
Let's differentiate two issues,
- To use Pd as a sample replay based game audio engine
- 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;
- Donate some existing models or patches
- Work as "procedural sound designer" to create sound objects.
- Help out the team by guiding others to do this.
- 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)
- 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@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