[PD] Porting PD to Java (feasible with Cibyl?)

[Hans-Christoph Steiner]

libpd is really going to be a reference for what you can remove in  
s_inter.c   Most of what s_inter.c does is starting Pd and Pd's GUI.   
Check out the startup sequence in libpd.  Or really, just work with  
libpd directly, or are you already?

.hc

On Jul 27, 2011, at 4:12 PM, Andrew VanderVeen wrote:

> Thanks for the help, I appreciate it.
>
> Right now I'm just going through and removing references to  
> functions in each those files (s_loader.c, s_inter.c, x_net.c),  
> replacing them with stuff that will silently fail or do nothing, and  
> things are compiling well.
>
> Just to be sure (s_inter.c seems very large), if I completely remove  
> s_inter.c, am I going to break things, or should I be writing basic  
> functions (return 0 or -1) for each of the functions in socket.h?
>
> Again, thanks for the quick responses. This is really helping me out  
> a lot!
>
> -Andrew
>
> On Wed, Jul 27, 2011 at 3:39 PM, Hans-Christoph Steiner  
> <hans at at.or.at> wrote:
>
>
> In terms of feasibility, most of Pd is really plain C, so it should  
> be an easy port.  The only things that are not are the various I/O  
> methods (audio, midi, files, net, etc).  You'll need to write a  
> audio I/O driver, that'll probably be in Java.  You can look at the  
> Android port for an example.  libpd talks to the Java audio I/O via  
> a JNI lib.
>
>
> On Jul 27, 2011, at 2:28 PM, Mathieu Bouchard wrote:
>
> On Wed, 27 Jul 2011, Andrew VanderVeen wrote:
>
> So, since it's not exactly ideal to re-implement these headers in  
> Java (I don't even know if it's possible), is there a way that I can  
> pull these files out of the pure data project?  I'm not entirely  
> sure what they do, or how essential/core they are to the project.   
> Can I just remove certain (unneeded?) functionality?
>
> No <dlfcn.h> means no externals except by explicit linkage.
>
> Yeah, basically, if you want to add extra objects, then'll need to  
> be compiled and linked in before processing with cibyl.  You can  
> ignore that stuff to get things working, indeed the iOS version does  
> not use it at all.  Then later you can figure out how to include  
> external objects if need be.
>
>
> No <socket.h> means no gui, no [netsend] and no [netreceive].
>
>
> Since you're most interested in the libpd approach, then you don't  
> need to worry about the socket for the GUI.  That you can skip.   
> Indeed that's the normal way with libpd.  As for [netsend] and  
> [netreceive], those are a way
>
> .hc
>
>
>
> ----------------------------------------------------------------------------
>
> Programs should be written for people to read, and only incidentally  
> for machines to execute.
>  - from Structure and Interpretation of Computer Programs
>
>



----------------------------------------------------------------------------

Looking at things from a more basic level, you can come up with a more  
direct solution... It may sound small in theory, but it in practice,  
it can change entire economies.     - Amy Smith


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110727/50c0dfb6/attachment.htm>