I am trying to make available 2 PSEYE cameras on an Ubuntu linux machine. Unfortunately, they show up with the same name and using
String[] cameras = Capture.list();
for (int i = 0; i < numCams; ++i) {
cams[i] = new Capture(this, camWidth, camHeight, cameras[i], camFps);
cams[i].start();
}
does not yield in the right behaviour.
Looking at the sourcecode of the Capture constructor shows me that it only searches for the first occurrence of the name and returns that object.
AFICS a constructor that lets me directly access the object at the index of the list would solve the problem, however, I am not at all experienced in writing/adapting processing libraries.
Any help much appreciated, I am happy to test out possible solutions or even install/configure eclipse if someone could guide me through the necessary steps!
to download the source code to the current folder in your shell.
sudo apt install ant
if you don’t have ant yet. Finally
ant build
which should build the library as a jar binary. I don’t remember if you then have to copy the produced library (which might be in a sub folder) to the Processing libraries folder, replacing the existing one and then restart your sketch.
@neilcsmith Does Praxislive work around this issue somehow? Or does it use the Processing Video library as it is?
PraxisLIVE has its own video library built directly on top of the GStreamer bindings. It doesn’t have this problem because you can set any GStreamer elements you want as a source, but defaults to device indexes on Linux. It’s also more efficient (than v2 beta) as it passes video buffers directly from GStreamer to the texture upload.
This video support might make it back to Processing. In the meantime @LFSaw why not give Processing a whirl in PraxisLIVE instead?!
I am not aware of PraxisLIVE yet, but, since I work with PS Eyes, I found a solution to my problem by the Java-port of the PS3EYEDriver project by diwi. This library also works on OSX (where the gstreamer-based implementation is creating a NULLpointer exception for even a single PS3Eye).
However, I could imagine that this seemingly “trivial to implement” feature for the Capture class might be worth looking into.
hmm… this is really weird… I did not really check the hex-codes (they are both the same…) but interestingly, changing something in the class file (the two lines) magically made the camera work…
This is literally the only thing I changed.
Now, changing it back (obviously) results in the code perfectly working… My java (jar/compile/*) knowledge is nearly non-existing, could it be that touching the code overwrites the .jar file (sitting somwhere in the package)?