I got Processing up and running with a webcam using JMyron and blobDetection. This is a video I took of my fingers with a small LED shining on them in a dark room.
The next step will be to write a small C++ program using the oscpack and listen to messages sent by oscP5 within Processing on another computer.
4 comments:
I got oscP5 on the webcam side to talk to oscpack on the openGL side. However, we now have a problem. The listener that gets the message is ALWAYS listening (as it should be). But the openGL display loop is always going too. We can't do both at once unless we use threads or something similar. We can't alternate display and checking for messages, because we might miss messages.
After some googling for threads and oscpack, I stumbled upon another Google summer of code project called CLAM. It seems like they have a class implemented to let oscpack run as a thread and store each message it receives into a queue. Then you can make a call to take a peek at the message queue whenever you want. This could be the solution we're looking for. We'll talk about it at the meeting tomorrow...
- Jae
Here's the url for the thread extension to oscpack:
OSCControlDispatcher
I've tried to slap the CLAM example onto my code, but it's been horribly unsuccessful -- too many dependencies. I don't want to install the package, but just use a part of it.
So I'm thinking I'll have to write my own similar version of the class that I referenced in the previous comment.
We are up and running with threads. One thread is spawned for listening to messages while the parent thread busies itself with the display loop.
I haven't tested this on video yet, so frame rate may be an issue, but I guess we'll see....
Post a Comment