Hi!
Blender foundation together with crystalspace community just started making a kickass game http://apricot.blender.org.
We are thinking about using puredata to handle the music system (and maybe also some more cool stuff), but I think it'd be important to be able to have puredata as a library to link and control it easier from the game (instead of running a separate process and handling all communication with osc socket). I think there was some work in progress in this direction with desiredata but i cant be so sure... can anybody confirm on the status of this or if its feasible at all? My general idea on the subject is we should be able to run pd as a game engine plugin (instead of our own sound system for example), and handle opening the different patches for different stuff, as well of communicating with each of them.
Another thing, i'd like to hear from people who have used pd in games to know exactly what you did with it.
I am one of main devs for the project, and i have great puredata experience, so i think it'd be very interesting to work on this, still, we are very time pressed so integrating pd should not pose too much runtime or distribution basic problems, specially the lib thing distresses me (and handling of patches from there). Just so everyone knows, we do have osc receiver in the game engine, so we could basically plug pd stuff to anywhere from object positions to shader variables to do funky stuff, sending osc messages to pd as part of logic also is not a problem.
Cheers!
Pablo
Hey Pablo,
Yes it is feasible. So Apricot is to use Pd?
You literally caught me walking out the door for a few days off. So I'll get back to this discussion Thursday.
I've pretty much got an object for every sound you need in a game including detailed parameterisation and some already with OSC bindings.
We have several people here on list who are enthusiastic about working such a project and I am in regular touch with other researchers and programmers who are developing this area.
good wishes to you, chat soon, Andy
On Mon, 11 Feb 2008 12:17:26 +0100 Pablo Martin caedes@sindominio.net wrote:
Hi!
Blender foundation together with crystalspace community just started making a kickass game http://apricot.blender.org.
We are thinking about using puredata to handle the music system (and maybe also some more cool stuff), but I think it'd be important to be able to have puredata as a library to link and control it easier from the game (instead of running a separate process and handling all communication with osc socket). I think there was some work in progress in this direction with desiredata but i cant be so sure... can anybody confirm on the status of this or if its feasible at all? My general idea on the subject is we should be able to run pd as a game engine plugin (instead of our own sound system for example), and handle opening the different patches for different stuff, as well of communicating with each of them.
Another thing, i'd like to hear from people who have used pd in games to know exactly what you did with it.
I am one of main devs for the project, and i have great puredata experience, so i think it'd be very interesting to work on this, still, we are very time pressed so integrating pd should not pose too much runtime or distribution basic problems, specially the lib thing distresses me (and handling of patches from there). Just so everyone knows, we do have osc receiver in the game engine, so we could basically plug pd stuff to anywhere from object positions to shader variables to do funky stuff, sending osc messages to pd as part of logic also is not a problem.
Cheers!
Pablo
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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
On Feb 11, 2008, at 9:55 AM, Pablo Martin 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.
Hey Pablo!
You should know that Pd is the sound engine for EA's Spore (http://
www.spore.com/ ). If that doesn't convince you that Pd will work in
a game, I don't know what will. ;) I am not sure how much of EA's
code made it back into Pd itself. I suspect that the new callback
support in 0.41 is related.
As for using Pd as a library, I don't think that is feasible. You
need to have a realtime scheduler in order to use Pd, and I don't
think Pd is so modular that you can separate the objects from the Pd
scheduler.
.hc
kill your television
Hans-Christoph Steiner escribió:
On Feb 11, 2008, at 9:55 AM, Pablo Martin 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.
Hey Pablo!
You should know that Pd is the sound engine for EA's Spore (http:// www.spore.com/ ).
Yeah, i knew :)
As for using Pd as a library, I don't think that is feasible. You
need to have a realtime scheduler in order to use Pd, and I don't
think Pd is so modular that you can separate the objects from the Pd
scheduler.
Mmmm, not so sure what you mean (i suppose the pd internal scheduler?), but i guess the whole thing could be put in a thread maybe... don't know why but it's always seemed like it good be a good idea to have pd as a library (after using it too many times as external program)... it'd make such a cool "internal" sound system. Still... probably we could handle running it as a separate process, but maybe i've had too many bad experiences with that :P....
Any ideas how desiredata handles this? I thought they actually have a "libpd" part in the code tree...
Cheers!
Pablo
On Tue, Feb 12, 2008 at 11:03:13AM +0100, Pablo Martin wrote:
Mmmm, not so sure what you mean (i suppose the pd internal scheduler?), but i guess the whole thing could be put in a thread maybe... don't know why but it's always seemed like it good be a good idea to have pd as a library (after using it too many times as external program)... it'd make such a cool "internal" sound system. Still... probably we could handle running it as a separate process, but maybe i've had too many bad experiences with that :P....
I agree that it would be better to run it as a library. I did a bit of an experiment, putting hte following into the Pd makefile in the src directory:
libpd.so: $(OBJ) $(BIN_DIR)
cd ../obj; $(LD) $(DBG_CFLAGS) -shared -soname ../bin/libpd.so.1
-o ../bin/libpd.so -lc $(OBJ) $(LIB)
Then I tested it with a Python program something like this:
import ctypes pd = ctypes.CDLL("./libpd.so") pd.pd_init() pd.sys_startgui("./pd-gui")
Which seems to vaguely work, although I haven't made it make a sound yet. Anyway, I think this could be a good strategy for tying Pd into Blender. I would suggest running Pd in a separate thread and using a mutexed queue to pass it messages which would then be read from the queue inside the same thread where Pd was running and passed into Pd in that thread by using the standard Pd message generating functions. So basically the game engine and Pd-in-a-thread would only communicate by message passing over this mutexed queue which should eliminate deadlocks etc.
Best,
Chris.
Hi!
Chris McCormick escribió:
(...) Which seems to vaguely work, although I haven't made it make a sound yet. Anyway, I think this could be a good strategy for tying Pd into Blender. I would suggest running Pd in a separate thread and using a mutexed queue to pass it messages which would then be read from the queue inside the same thread where Pd was running and passed into Pd in that thread by using the standard Pd message generating functions. So basically the game engine and Pd-in-a-thread would only communicate by message passing over this mutexed queue which should eliminate deadlocks etc.
Yeah that would be the idea I think. (sounds good to me at least).
Cheers!
Pablo
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
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
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.
These points are issues in Pd that vessel/lua~ by Graham Wakefiled tries to solve in a way, where "in a way" means embedding Lua as a scripting language for DSP inside of a Pd/Max object, which would make using Pd in a game engine kind of superfluous - as you could directly embed Vessel into the game instead of into Pd first. ;)
Ciao
Frank Barknecht
On Thu, 14 Feb 2008 17:52:59 +0100 Frank Barknecht fbar@footils.org wrote:
Hallo, Andy Farnell hat gesagt: // Andy Farnell wrote:
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.
These points are issues in Pd that vessel/lua~ by Graham Wakefiled tries to solve in a way, where "in a way" means embedding Lua as a scripting language for DSP inside of a Pd/Max object, which would make using Pd in a game engine kind of superfluous - as you could directly embed Vessel into the game instead of into Pd first. ;)
Hmm yes, that's a crazy roundabout way. Is there something we can learn from Grahams work/Vessel to do it inside Pd?
Ciao
Frank Barknecht
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Thu, Feb 14, 2008 at 10:40 AM, Andy Farnell padawan12@obiwannabe.co.uk wrote:
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)
SuperCollider pretty much covers this list and it seems well suited for working with a game.
Hmmm, so far we have suggestions to use Lua and SC :)
There are many good reasons to choose other languages.
Csound - history, stability, SAOL encapsualtion Nyquist (LISP) lends itself well to parallelism SC - instance management/polyphony, recursion
But let's focus on Pd since this is Pd list and the proposed plan is to use Pd with Blender as EA have done :)
Mark Danks suggested to me that they found it rather trivial to accomplish. The challenges I suggest would make a 'perfect world', but aren't essential to a basic working system.
The power of Pd, over CS, SC, LISP, Lua is *developmenmt time*
Games require numerous resources to be created, quickly and in an easily maintainable way. This, and being designed for realtime execution, are Pds enormous strengths.
On Thu, 14 Feb 2008 11:02:32 -0600 "chris clepper" cgclepper@gmail.com wrote:
On Thu, Feb 14, 2008 at 10:40 AM, Andy Farnell padawan12@obiwannabe.co.uk wrote:
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)
SuperCollider pretty much covers this list and it seems well suited for working with a game.
hi, I want to help with that project. I would have spend time on research and development into that direction also without the apricot game (for school), and was looking for a possibility like this. so the combination with blender and working on a real project is perfect. who is coordinating the efforts? regarding feasibility, I am not sure how easy the whole thing is. you for example will want to do all the sound/driver settings from within the game, which means pd has to be able to change this by sending commands. as far as I know this is not possible with current core pd. but all the overall work on sound/patches could be started immediately, and network connection to send game parameters is also existing already (and can still be changed later). marius.
Pablo Martin wrote:
Hi!
Blender foundation together with crystalspace community just started making a kickass game http://apricot.blender.org.
We are thinking about using puredata to handle the music system (and maybe also some more cool stuff), but I think it'd be important to be able to have puredata as a library to link and control it easier from the game (instead of running a separate process and handling all communication with osc socket). I think there was some work in progress in this direction with desiredata but i cant be so sure... can anybody confirm on the status of this or if its feasible at all? My general idea on the subject is we should be able to run pd as a game engine plugin (instead of our own sound system for example), and handle opening the different patches for different stuff, as well of communicating with each of them.
Another thing, i'd like to hear from people who have used pd in games to know exactly what you did with it.
I am one of main devs for the project, and i have great puredata experience, so i think it'd be very interesting to work on this, still, we are very time pressed so integrating pd should not pose too much runtime or distribution basic problems, specially the lib thing distresses me (and handling of patches from there). Just so everyone knows, we do have osc receiver in the game engine, so we could basically plug pd stuff to anywhere from object positions to shader variables to do funky stuff, sending osc messages to pd as part of logic also is not a problem.
Cheers!
Pablo
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pdvst, by Joe Sarlo, does something related (embeds Pd as a VST plug-in; windows only). It uses the Pd executable, plugging in a user-supplied scheduler that manages audio and control I/O to the calling program. Since there might be several Pdvst plug-ins active at a time, each gets its own address space, which is probably more work than you need to do for the game.
It should be possible simply to compile Pd without including s_main.c or s_entry.c, call the setup routines that sys_main does and then just write your own main loop to replace m_callbackscheduler() or m_pollingscheduler() depending on which side of that religious divide you want to occupy :)
M
On Tue, Feb 12, 2008 at 12:41:30PM -0500, marius schebella wrote:
hi, I want to help with that project. I would have spend time on research and development into that direction also without the apricot game (for school), and was looking for a possibility like this. so the combination with blender and working on a real project is perfect. who is coordinating the efforts? regarding feasibility, I am not sure how easy the whole thing is. you for example will want to do all the sound/driver settings from within the game, which means pd has to be able to change this by sending commands. as far as I know this is not possible with current core pd. but all the overall work on sound/patches could be started immediately, and network connection to send game parameters is also existing already (and can still be changed later). marius.
Pablo Martin wrote:
Hi!
Blender foundation together with crystalspace community just started making a kickass game http://apricot.blender.org.
We are thinking about using puredata to handle the music system (and maybe also some more cool stuff), but I think it'd be important to be able to have puredata as a library to link and control it easier from the game (instead of running a separate process and handling all communication with osc socket). I think there was some work in progress in this direction with desiredata but i cant be so sure... can anybody confirm on the status of this or if its feasible at all? My general idea on the subject is we should be able to run pd as a game engine plugin (instead of our own sound system for example), and handle opening the different patches for different stuff, as well of communicating with each of them.
Another thing, i'd like to hear from people who have used pd in games to know exactly what you did with it.
I am one of main devs for the project, and i have great puredata experience, so i think it'd be very interesting to work on this, still, we are very time pressed so integrating pd should not pose too much runtime or distribution basic problems, specially the lib thing distresses me (and handling of patches from there). Just so everyone knows, we do have osc receiver in the game engine, so we could basically plug pd stuff to anywhere from object positions to shader variables to do funky stuff, sending osc messages to pd as part of logic also is not a problem.
Cheers!
Pablo
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
that sounds promising! maybe still a little too ambitious for someone who does not know the pd source at all (aka me). is there an overall introductory explanation of how the various source codes components work together besides the source code and in code documentation itself? marius.
Miller Puckette wrote:
Pdvst, by Joe Sarlo, does something related (embeds Pd as a VST plug-in; windows only). It uses the Pd executable, plugging in a user-supplied scheduler that manages audio and control I/O to the calling program. Since there might be several Pdvst plug-ins active at a time, each gets its own address space, which is probably more work than you need to do for the game.
It should be possible simply to compile Pd without including s_main.c or s_entry.c, call the setup routines that sys_main does and then just write your own main loop to replace m_callbackscheduler() or m_pollingscheduler() depending on which side of that religious divide you want to occupy :)
M
On Tue, Feb 12, 2008 at 12:41:30PM -0500, marius schebella wrote:
hi, I want to help with that project. I would have spend time on research and development into that direction also without the apricot game (for school), and was looking for a possibility like this. so the combination with blender and working on a real project is perfect. who is coordinating the efforts? regarding feasibility, I am not sure how easy the whole thing is. you for example will want to do all the sound/driver settings from within the game, which means pd has to be able to change this by sending commands. as far as I know this is not possible with current core pd. but all the overall work on sound/patches could be started immediately, and network connection to send game parameters is also existing already (and can still be changed later). marius.
Pablo Martin wrote:
Hi!
Blender foundation together with crystalspace community just started making a kickass game http://apricot.blender.org.
We are thinking about using puredata to handle the music system (and maybe also some more cool stuff), but I think it'd be important to be able to have puredata as a library to link and control it easier from the game (instead of running a separate process and handling all communication with osc socket). I think there was some work in progress in this direction with desiredata but i cant be so sure... can anybody confirm on the status of this or if its feasible at all? My general idea on the subject is we should be able to run pd as a game engine plugin (instead of our own sound system for example), and handle opening the different patches for different stuff, as well of communicating with each of them.
Another thing, i'd like to hear from people who have used pd in games to know exactly what you did with it.
I am one of main devs for the project, and i have great puredata experience, so i think it'd be very interesting to work on this, still, we are very time pressed so integrating pd should not pose too much runtime or distribution basic problems, specially the lib thing distresses me (and handling of patches from there). Just so everyone knows, we do have osc receiver in the game engine, so we could basically plug pd stuff to anywhere from object positions to shader variables to do funky stuff, sending osc messages to pd as part of logic also is not a problem.
Cheers!
Pablo
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
No -- there ought to be, but it never makes it to the top of the priority heap.
M
On Tue, Feb 12, 2008 at 01:30:11PM -0500, marius schebella wrote:
that sounds promising! maybe still a little too ambitious for someone who does not know the pd source at all (aka me). is there an overall introductory explanation of how the various source codes components work together besides the source code and in code documentation itself? marius.
Miller Puckette wrote:
Pdvst, by Joe Sarlo, does something related (embeds Pd as a VST plug-in; windows only). It uses the Pd executable, plugging in a user-supplied scheduler that manages audio and control I/O to the calling program. Since there might be several Pdvst plug-ins active at a time, each gets its own address space, which is probably more work than you need to do for the game.
It should be possible simply to compile Pd without including s_main.c or s_entry.c, call the setup routines that sys_main does and then just write your own main loop to replace m_callbackscheduler() or m_pollingscheduler() depending on which side of that religious divide you want to occupy :)
M
On Tue, Feb 12, 2008 at 12:41:30PM -0500, marius schebella wrote:
hi, I want to help with that project. I would have spend time on research and development into that direction also without the apricot game (for school), and was looking for a possibility like this. so the combination with blender and working on a real project is perfect. who is coordinating the efforts? regarding feasibility, I am not sure how easy the whole thing is. you for example will want to do all the sound/driver settings from within the game, which means pd has to be able to change this by sending commands. as far as I know this is not possible with current core pd. but all the overall work on sound/patches could be started immediately, and network connection to send game parameters is also existing already (and can still be changed later). marius.
Pablo Martin wrote:
Hi!
Blender foundation together with crystalspace community just started making a kickass game http://apricot.blender.org.
We are thinking about using puredata to handle the music system (and maybe also some more cool stuff), but I think it'd be important to be able to have puredata as a library to link and control it easier from the game (instead of running a separate process and handling all communication with osc socket). I think there was some work in progress in this direction with desiredata but i cant be so sure... can anybody confirm on the status of this or if its feasible at all? My general idea on the subject is we should be able to run pd as a game engine plugin (instead of our own sound system for example), and handle opening the different patches for different stuff, as well of communicating with each of them.
Another thing, i'd like to hear from people who have used pd in games to know exactly what you did with it.
I am one of main devs for the project, and i have great puredata experience, so i think it'd be very interesting to work on this, still, we are very time pressed so integrating pd should not pose too much runtime or distribution basic problems, specially the lib thing distresses me (and handling of patches from there). Just so everyone knows, we do have osc receiver in the game engine, so we could basically plug pd stuff to anywhere from object positions to shader variables to do funky stuff, sending osc messages to pd as part of logic also is not a problem.
Cheers!
Pablo
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Yes, but... why doesnt pd already export some kind of library? In a way it sucks that such a powerful engine is trapped inside a binary in that way, a good library would allow embedding in better ways, as well as ease experiments like desiredata or any others that might follow (thats my opinion at least).
I'm asking because its veery strange to me that this didn't happen already. Maybe some design decision?
I know we can hack something though (like the vst guy), but still...
Cheers!
Pablo
Miller Puckette escribió:
No -- there ought to be, but it never makes it to the top of the priority heap.
M
On Tue, Feb 12, 2008 at 01:30:11PM -0500, marius schebella wrote:
that sounds promising! maybe still a little too ambitious for someone who does not know the pd source at all (aka me). is there an overall introductory explanation of how the various source codes components work together besides the source code and in code documentation itself? marius.
Miller Puckette wrote:
Pdvst, by Joe Sarlo, does something related (embeds Pd as a VST plug-in; windows only). It uses the Pd executable, plugging in a user-supplied scheduler that manages audio and control I/O to the calling program. Since there might be several Pdvst plug-ins active at a time, each gets its own address space, which is probably more work than you need to do for the game.
It should be possible simply to compile Pd without including s_main.c or s_entry.c, call the setup routines that sys_main does and then just write your own main loop to replace m_callbackscheduler() or m_pollingscheduler() depending on which side of that religious divide you want to occupy :)
M
On Tue, Feb 12, 2008 at 12:41:30PM -0500, marius schebella wrote:
hi, I want to help with that project. I would have spend time on research and development into that direction also without the apricot game (for school), and was looking for a possibility like this. so the combination with blender and working on a real project is perfect. who is coordinating the efforts? regarding feasibility, I am not sure how easy the whole thing is. you for example will want to do all the sound/driver settings from within the game, which means pd has to be able to change this by sending commands. as far as I know this is not possible with current core pd. but all the overall work on sound/patches could be started immediately, and network connection to send game parameters is also existing already (and can still be changed later). marius.
Pablo Martin wrote:
Hi!
Blender foundation together with crystalspace community just started making a kickass game http://apricot.blender.org.
We are thinking about using puredata to handle the music system (and maybe also some more cool stuff), but I think it'd be important to be able to have puredata as a library to link and control it easier from the game (instead of running a separate process and handling all communication with osc socket). I think there was some work in progress in this direction with desiredata but i cant be so sure... can anybody confirm on the status of this or if its feasible at all? My general idea on the subject is we should be able to run pd as a game engine plugin (instead of our own sound system for example), and handle opening the different patches for different stuff, as well of communicating with each of them.
Another thing, i'd like to hear from people who have used pd in games to know exactly what you did with it.
I am one of main devs for the project, and i have great puredata experience, so i think it'd be very interesting to work on this, still, we are very time pressed so integrating pd should not pose too much runtime or distribution basic problems, specially the lib thing distresses me (and handling of patches from there). Just so everyone knows, we do have osc receiver in the game engine, so we could basically plug pd stuff to anywhere from object positions to shader variables to do funky stuff, sending osc messages to pd as part of logic also is not a problem.
Cheers!
Pablo
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Part of the trouble is that only one instance of Pd can live in any given address space (because of widespread use of static variables). This is fine for linking Pd into a video game where you'd only want one instance, but if you want multiple ones you'd want to sprout separate Pd processes with pipes or sockets. Not that I don't think that would be a useful trick!
cheers M
On Wed, Feb 13, 2008 at 06:52:08PM +0100, Pablo Martin wrote:
Yes, but... why doesnt pd already export some kind of library? In a way it sucks that such a powerful engine is trapped inside a binary in that way, a good library would allow embedding in better ways, as well as ease experiments like desiredata or any others that might follow (thats my opinion at least).
I'm asking because its veery strange to me that this didn't happen already. Maybe some design decision?
I know we can hack something though (like the vst guy), but still...
Cheers!
Pablo
Miller Puckette escribi?:
No -- there ought to be, but it never makes it to the top of the priority heap.
M
On Tue, Feb 12, 2008 at 01:30:11PM -0500, marius schebella wrote:
that sounds promising! maybe still a little too ambitious for someone who does not know the pd source at all (aka me). is there an overall introductory explanation of how the various source codes components work together besides the source code and in code documentation itself? marius.
Miller Puckette wrote:
Pdvst, by Joe Sarlo, does something related (embeds Pd as a VST plug-in; windows only). It uses the Pd executable, plugging in a user-supplied scheduler that manages audio and control I/O to the calling program. Since there might be several Pdvst plug-ins active at a time, each gets its own address space, which is probably more work than you need to do for the game.
It should be possible simply to compile Pd without including s_main.c or s_entry.c, call the setup routines that sys_main does and then just write your own main loop to replace m_callbackscheduler() or m_pollingscheduler() depending on which side of that religious divide you want to occupy :)
M
On Tue, Feb 12, 2008 at 12:41:30PM -0500, marius schebella wrote:
hi, I want to help with that project. I would have spend time on research and development into that direction also without the apricot game (for school), and was looking for a possibility like this. so the combination with blender and working on a real project is perfect. who is coordinating the efforts? regarding feasibility, I am not sure how easy the whole thing is. you for example will want to do all the sound/driver settings from within the game, which means pd has to be able to change this by sending commands. as far as I know this is not possible with current core pd. but all the overall work on sound/patches could be started immediately, and network connection to send game parameters is also existing already (and can still be changed later). marius.
Pablo Martin wrote:
Hi!
Blender foundation together with crystalspace community just started making a kickass game http://apricot.blender.org.
We are thinking about using puredata to handle the music system (and maybe also some more cool stuff), but I think it'd be important to be able to have puredata as a library to link and control it easier from the game (instead of running a separate process and handling all communication with osc socket). I think there was some work in progress in this direction with desiredata but i cant be so sure... can anybody confirm on the status of this or if its feasible at all? My general idea on the subject is we should be able to run pd as a game engine plugin (instead of our own sound system for example), and handle opening the different patches for different stuff, as well of communicating with each of them.
Another thing, i'd like to hear from people who have used pd in games to know exactly what you did with it.
I am one of main devs for the project, and i have great puredata experience, so i think it'd be very interesting to work on this, still, we are very time pressed so integrating pd should not pose too much runtime or distribution basic problems, specially the lib thing distresses me (and handling of patches from there). Just so everyone knows, we do have osc receiver in the game engine, so we could basically plug pd stuff to anywhere from object positions to shader variables to do funky stuff, sending osc messages to pd as part of logic also is not a problem.
Cheers!
Pablo
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
marius schebella wrote:
maybe still a little too ambitious for someone who does not know the pd source at all (aka me). is there an overall introductory explanation of how the various source codes components work together besides the source code and in code documentation itself? marius.
I wrote some stuff here about the startup structure on various platforms: http://lists.puredata.info/pipermail/pd-list/2005-09/031049.html
Martin
marius schebella a écrit :
hi,... I am not sure how easy the whole thing is. you for example will want to do all the sound/driver settings from within the game, which means pd has to be able to change this by sending commands. as far as I know this is not possible with current core pd.
It has always been possible to restart pd with new settings regarding sound drivers, buffer, etc...
but all the overall work on sound/patches could be started immediately, and network connection to send game parameters is also existing already (and can still be changed later). marius.
It would be great to have python modules that ease the communication between Blender and PureData, with FUDI or OSCx!
Pablo Martin wrote:
Hi!
Blender foundation together with crystalspace community just started making a kickass game http://apricot.blender.org.
We are thinking about using puredata to handle the music system (and maybe also some more cool stuff), but I think it'd be important to be able to have puredata as a library to link and control it easier from the game (instead of running a separate process and handling all communication with osc socket). I think there was some work in progress in this direction with desiredata but i cant be so sure... can anybody confirm on the status of this or if its feasible at all? My general idea on the subject is we should be able to run pd as a game engine plugin (instead of our own sound system for example), and handle opening the different patches for different stuff, as well of communicating with each of them.
Another thing, i'd like to hear from people who have used pd in games to know exactly what you did with it.
I am one of main devs for the project, and i have great puredata experience, so i think it'd be very interesting to work on this, still, we are very time pressed so integrating pd should not pose too much runtime or distribution basic problems, specially the lib thing distresses me (and handling of patches from there). Just so everyone knows, we do have osc receiver in the game engine, so we could basically plug pd stuff to anywhere from object positions to shader variables to do funky stuff, sending osc messages to pd as part of logic also is not a problem.
Cheers!
Pablo
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Patrice Colet wrote:
marius schebella a écrit :
hi,... I am not sure how easy the whole thing is. you for example will want to do all the sound/driver settings from within the game, which means pd has to be able to change this by sending commands. as far as I know this is not possible with current core pd.
It has always been possible to restart pd with new settings regarding sound drivers, buffer, etc...
yes, but that takes longer than just changing settings...
but all the overall work on sound/patches could be started immediately, and network connection to send game parameters is also existing already (and can still be changed later). marius.
It would be great to have python modules that ease the communication between Blender and PureData, with FUDI or OSCx!
why do you want to run all communication through python? or do you mean on the blender side? there are libraries (mrpeach and oscx, maybe even others) that do osc communication. marius.
hi!
marius schebella escribió:
Patrice Colet wrote:
marius schebella a écrit :
It would be great to have python modules that ease the communication between Blender and PureData, with FUDI or OSCx!
why do you want to run all communication through python? or do you mean on the blender side? there are libraries (mrpeach and oscx, maybe even others) that do osc communication. marius.
I think he means more something like a python module to easily start and stop puredata instances, manages patches and so on if that's even possible, while the communication itself would work over osc not even going through python (at least that's what i'd do).
Cheers!
Pablo
-
Andy Farnell -
chris clepper -
Chris McCormick -
Frank Barknecht -
Hans-Christoph Steiner -
marius schebella -
Martin Peach -
Miller Puckette -
Pablo Martin -
Patrice Colet