We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProcessing DevelopmentLibraries,  Tool Development › About porting a library to processing
Page Index Toggle Pages: 1
About porting a library to processing (Read 700 times)
About porting a library to processing
Nov 7th, 2008, 12:04pm
 
Hello,

For a university project we have a zcam (http://www.3dvsystems.com/), and the SDK provided is written in C++ (some .lib and .dll files), without the source code.
As I would like to use processing as a front end, I was wondering how can this be done. After a small research, one solution could be to establish a UDP connection that would act as a middleware, or I could possibly explore what can be done through JNI.
However I am not familiar with these concepts, and I was wondering if there could be a more efficient (and cleaner) approach.

Any help/advice would be really appreciated!
Thank you
Re: About porting a library to processing
Reply #1 - Nov 7th, 2008, 1:28pm
 
hi,
my first choice would be a networked solution, since you mention UDP. you might even consider to use OSC, a control message protocol, on top of UDP. many applications implement OSC already and since it is a network protocol, you could even do zcam on one machine and e.g. the visualization on another machine.
if you prefer native access instead, maybe you look into JNA (java native access), "JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code—no JNI or native code is required."
personally i would go for the networked solution though since it seems to be more flexible to me.
best,
andreas
Re: About porting a library to processing
Reply #2 - Nov 10th, 2008, 10:37am
 
Thank you very much for the quick reply.

We explored JNA a little, but finally will do something with opensound - seems to be simpler and more portable..

Cheers
Page Index Toggle Pages: 1