ofSetFrameRate, update and draw

beginners
#1

Hi there,
I’m trying to use LeapMotion to get the incoming data and feed a couple of threads. My question is about the ofSetFrameRate parameter and the update rate. Let me first depic a bit about the tprogram… in general terms, it is something like this

`void ofGrtApp::setup(){
myThread1.start();
myThread2.start();

}

void ofGrtApp::update(){
ofSetFrameRate(60);
vector hands = leap.getLeapHands(); //I start to get the LM data
int answer1 = myThread1.processthedata(vector);
int answer2 = myThread2.processthedata(vector);
}

void ofGrtApp::draw(){
//draw something with answer1
//draw something with answer2
}
`

So, it’s a pretty basic app. I could list my questions in this order:

  1. My understanding of the ofSetFrameRate parameter is that, it is the rate used to refresh the displayed image of the draw method? So, it has nothing to do with the refreshment rate of the LM?
  2. If the above is true… how could I modify the update method in order to slow down or adjust the LeapMotion frames retrieval? (I’ve already tried with sleep functions, but they mess up the program… it crashes) or, how does the update() rate works?
  3. In the threads, I’m using the ofxThreads library and I haven’t found the way to make them synchronize:

int answer1 = myThread1.processthedata(vector); int answer2 = myThread2.processthedata(vector);

I would need them to wait for each other…

I’m sorry if these are nooby questions, but I’ve been trying to understand how they work…

Any help is greatly appreciated!

Thanks!

#2

Hi Adrianna,

First let me preface by saying I’m new with oF and I know nothing about LeapMotion controllers or the ofxThreads addon. I think its pretty common to call ofSetFrameRate() in ofApp::setup(), so that its just called once. Calling it in ofApp::update() will call it at the prescribed rate, as both ofApp::update() and ofApp::draw() run once in a loop at the framerate. Lots of objects have their own “update” functions that are called in ofApp::update(), and maybe the LeapMotion controller needs its own “update” function which will retrieve its data and perhaps somehow filter it if needed (if its sending too much data or if its data is sporadic). I looked quickly online and there are a couple of oF addons for the LeapMotion. If you’re using something like that, maybe you just need to “filter” the data in the vector to make it manageable (average, median, bin, etc). The “filter” could run at whatever frequency you want if you either use a counter or use one of the ofGetElapsedTime-functions. You could also call leap.getLeapHands() at some interval outside of the framerate of ofApp (again with either a counter or with ofGetElapsedTime() functions).

I do know that when using OSC data in oF, there is an OSC object that handles the send/receive aspects of data, sets a bool for “new data”, and some other methods and variables. If the LeapMotion sends too much data for an OSC-type object, you could try looking at (and adapting) how the Kinect data is handled in oF. If the LeapMotion can generate OSC output, you could use an OSC object in oF to handle it. This would also allow you to use any OSC-type device for the input (TouchOSC, WiiMotes, etc). Finally, if the LeapMotion has its own object in oF that handles it, you could try augmenting the data at that level, rather than in ofApp::update(). In other words, the class that handles the LeapMotion may have some variables that augment it (frequency, threshold, offsets, etc).

As for synchronizing threads, I also have no experience, except that c++ seems to have ways of defining processes on threads that are either asynchronous or synchronized, and people seem to focus a lot of attention and effort in their code on thread setup and handling, especially with regard to variables, memory access, and thread priority. It seems complicated to me, especially when threads are trying to access the same data and are asynchronous. I know the Boost lib has some functions for multithreading, but I’m not sure if oF uses Boost for it or not. So it could be that you need to broaden beyond the ofxThreads addon to a more general handling of threads in c++. Sorry I can’t be more help on this. I hope someday to know this stuff; I’m learning quickly though.

OK good luck and hope this helps. Take care.

Tim

1 Like
#3

Tim,

thank you so much for providing me with this useful information. It gives me certain on some things that I had been suspecting. Your explanation was concise but right into the point, really really appreciate it! I{ve decided to stick with the original LM controller instead of the Listener because it makes me feel like I got more control at least in regards of the LM rate.
Oh, and for the thread join thing, I decided to keep running the thread all the way because seems to work better for me, although I did found how to join them, it is with the method waitForThread(), which waits for another thread to finish and then the calling thread dies.
Thank you so much!
Adriana

1 Like