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

[Miller Puckette]

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 at iem.at mailing list
> >>>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >>>>>
> >>>>>           
> >>>> _______________________________________________
> >>>> PD-list at iem.at mailing list
> >>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >>>>         
> >> _______________________________________________
> >> PD-list at iem.at mailing list
> >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >>     
> >
> > _______________________________________________
> > PD-list at iem.at mailing list
> > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> >
> >   
> 
> 
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list