How do you create class from a library as a thread class variable?

jaldunate

I am using the mindset library; that works perfect; but I am also working with a lot of graphics in the main thread, by using P5. Now, I am trying to log to a text file, the brainwave data, at a higher frequency than the drawing loop can handle, because the graphics are heavy. I created a new thread that can buffer and write data to the disc at the desired frequency, but now I need to poll the headset at this frequency; or otherwise I will just get duplicate points along the time.

When you call an instance of the mindset, you do so by

mindSet = new MindSet(this, "/dev/cu.MindWaveMobile-DevA");

I observed that If I place this statement in the main thread, say, the setup(); it will trigger other functions such as

` void meditationEvent(int meditationLevel) {}

`

But these methods will run at main thread timing, and therefore I will not get a higher sampling rate than the framerate (is that true?) or at least, will share the thread resources with the drawing functions, which is not ok.

Then, I tried to call the mindSet = new MindSet(this, "/dev/cu.MindWaveMobile-DevA"); inside an init function of the thread

class Logger extends Thread { (...) public void init(){ mindSet = new MindSet(this, "/dev/cu.MindWaveMobile-DevA"); } (...) }

In this case, there will be a compiling error, telling me that "The constructor diablu.processing.mindset.MindSet(Logger, String) does not exist. This is because the thread is a class named Logger, which is obviously an unexpected class for the library.

So there are many ways out:

• can I somehow provide the library with some sub property of the threading class that would be admitted?
• can i declare the mindset as a separate thread and communicate Logger thread with a new mindset thread?
• can I ensure in other ways that the mindset library will not share the thread space with the main thread?
• Is there a way that I can tweak the library with not much java knowledge?
• Is there an easier solution that I am overlooking?

Lots of thanks for at least reading!

KevinWorkman

But these methods will run at main thread timing, and therefore I will not get a higher sampling rate than the framerate (is that true?)

I'm not sure I follow this logic. Just because the meditationEvent() function is called on the main thread doesn't mean that it's called with the same timing as the draw() function. For example, you can have several mouseMoved() functions between two calls to the draw() function. Test this out by changing the frame rate to 1 and seeing how many meditationEvent() calls you get!

It looks like the library needs an instance of PApplet which it then (probably using reflection) finds the meditationEvent() function to call. I get that you're trying to get calls to the meditationEvent() function on another thread, but the way you're going about it (extending Thread and passing that into the library) doesn't make a ton of sense. Even if that would compile, nothing is telling the library to put the call on that Thread!

The first thing you need to do is confirm that you actually need threading. I would bet that you don't. You're assuming that meditationEvent() will be limited by the frame rate, and I doubt that's the case.

But if it is the case, then what you want to do is this: first, set up a normal single-threaded sketch that successfully calls the meditationEvent() on the main thread.

Then, create a data structure that you add the events to. You do this addition from the main thread.

Then, create a new Thread that processes the events in that data structure. There are about a million and one ways to do this, and Google is your friend, but you might start out looking at the BlockingQueue interface and the classes that implement it.

jaldunate

Thanks a lot, Kevin!.

You are right that the function calls will not be limited to the frame rate. It was not a smart thought after havin used several tuio points for each frame in other application. You seem to know more about the java side, which is what I am lacking. For instance, I have no idea what effect has in the library, when you provide a thisas parameter. I guess it searches for the callbacks in there. If the library object is instanced in the default void setup(); does it mean that it will share resources with the drawing thread?;

also, if the functions that are going to be called by the library (such as meditationEvent()) are declared otside, in the main processing sketch, and not inside a thread class; but called by a thread; will them be sharing resources with the processing sketch, or with the thread?

It was helpful to see that the required parameter should be of the PApplet type. If I somehow find the way to get the PApplet of the thread (is that even a thing?), I would be able to provide it as parameter. But well, I trust you if you say that it doesn't make that much sense.

KevinWorkman

For instance, I have no idea what effect has in the library, when you provide a this as parameter.

There is nothing too magical going on. The this keyword just references the current instance. You know how some functions require objects as a parameter? (Like the image() function requiring an instance of PImage as a parameter.) Well, some functions require an instance of PApplet. Your sketch is a PApplet (in Java terms, your sketch is a class that extends PApplet), and you can reference it using the this keyword.

(This glosses over the fact that the library probably uses reflection to find the functions which is a little magical, but that's outside what we're talking about.)

If the library object is instanced in the default void setup(); does it mean that it will share resources with the drawing thread?;

I'm not sure what you mean. Which resources are you talking about specifically?

also, if the functions that are going to be called by the library (such as meditationEvent()) are declared otside, in the main processing sketch, and not inside a thread class; but called by a thread; will them be sharing resources with the processing sketch, or with the thread?

Again, I'm not sure what resources you're talking about here. But the short answer is that any variables you have declared in your sketch will be shared by any Threads you have running inside your sketch.

If I somehow find the way to get the PApplet of the thread (is that even a thing?), I would be able to provide it as parameter.

No, that's not a thing. You only have one PApplet, and it's the "parent" of everything else. It is your sketch. Try looking at the generated Java to get a better idea of what I'm talking about.

But I will say that you seem to be focusing on Threads a little too much. I thought you said the timing of the library events wasn't limited by the framerate? Since that's the case, why are you still trying to use threading?

Threading might help with a few very specific things, but it isn't a catch-all solution. Think about it this way: you can't control which Thread the events are fired on. You don't want to. So trying to pass a thread into the library is a bit of a wild goose chase.

The events will be fired on the main drawing/event thread. That's what you want. From there you could use another thread to process the event, but honestly that's probably overkill for your purposes.