In Processing 0135 Beta, Serial.available() will never return a non-zero value if the video
library has also been imported. This has been confirmed to be true using 3 seprate video input
devices on Mac OS X 10.4.11 : a lego-branded logitec quickcam web, an old-style logitec
quickcam, and a sony video camera connected via firewire.

Steps to reproduce the problem:
Write any sketch which imports (and preferable uses) both the native video and serial libraries.
A sample sketch is included below.
Expected behavior: the sketch will run, and will cycle through the different cases as they
happen. Any calls to Serial.available() will return the proper number of bytes.
Actual behavior: The sketch complies and runs, but will hang and loop inefinately inside case
1, as Serial.available() never returns any value other than zero, even when bytes SHOULD be
available (as recorded by arduino-0010's serial monitor (nb: issue persists, even without
arduino-0010 running)).
See also:http://processing.org/discourse/yabb_beta/YaBB.cgi?
board=Electronics;action=display;num=1213888862

I am available to do as much testing as is required. Please contact me either via email or the
discourse forums.

Sample sketch (thanks ro rrrufusss for (lots of) help is writing this):

import processing.video.*;
import processing.serial.*;

Serial arduino;

PImage nolaser;
PImage laser;

Capture video;

int currentState = 0;

void setup() {
size(640, 240); //So we can display two side-by-side images
println(Capture.list());
video = new Capture(this, 320, 240, 1); //About the size my camera is, and on a slow
framerate.
arduino = new Serial(this, "/dev/tty.usbserial-A4001tLy", 9600); // Start the arduino
arduino.write('A'); //Initialize communication

println("setup done");
}

void draw()
{
switch( currentState )
{
case 0: // laser off, get a frame (when available)
if( video.available() )
{
video.read();
image(video, 0, 0);
arduino.write('G');
currentState = 1;
}
break;

case 1: // waiting for "laser on" confirmation
if( arduino.available() > 0 )
{
arduino.read();
currentState = 2;
}
break;

case 2: // laser is on, get a frame (when available)
if( video.available() )
{
video.read();
image(video, 0, 0);
arduino.write('F');

currentState = 3;
}
break;

case 3: // waiting for "laser off" confirmation
if( arduino.available() > 0 )
{
arduino.read();
currentState = 0; // repeat the cycle..
}
break;
}
}

edit]
Code which demonstrates the bug

This is the same as the sample code included in the initial post; however, it
is conveniently located inside a .pde file.

edit]
The code loaded onto the Arduino

This is the code running on the Arduino board when the bug appears.

dan shiffman mentioned that he may have seen this with a student before,
and that they managed to get around it by fiddling with the order in which
the libraries were started in the program. he's checking further.

Tried fiddling with the order; didn't do anything, sorry.

rrrufusss tried my sketch on his arduino board and reported that it worked without issue.
Here is what he reports as his specs:

computer: Macbook pro, intel cpu, running OS 10.4

arduino: usb, the older kind with the ATmega8

camera: built-in iSight in the laptop

No usb hub, arduino is plugged directly into the usb port on the laptop.

Because he is at least running a mac, i would venture the guess that this is somehow related
to my specific camera setup. Moving my camera to be directly connected, rather than
connected through a hub seemed to have no effect. My current guess is that this is related
somehow either to my setup (USB camera, 3rd party macam driver) or to some other
software I have installed.

I have posted a workaround to my specific issue in the above-mentioned thread on discourse,
but if anyone was actually trying to receive feedback, rather than just delay, such a
workaround would be useless.

(In reply to comment #3)
>
>
>
> Additional Comment #3 From
>
> fry
> 2008-06-20 06:09
>
> <!--
> addReplyLink(3); //-->[reply]
>
>
>
>
> dan shiffman mentioned that he may have seen this with a student before,
> and that they managed to get around it by fiddling with the order in which
> the libraries were started in the program. he's checking further.
>
>

out of curiosity, could you try this with release 0146?

No, sorry (tested in 0147).

The new behavior is to read one fram of video and then fail as soon as the serial device is
written to. However, the serial device works correctly (The demo sketch stalls because it is
waiting for video, however.)

If theres anything more (more tests you want me to run, for example) that I can do, I would be
glad to do so.

this is related to bug #882, i'm assuming if we get a fix for that, this
problem will be taken care of as well. so at least i have a test case that
i can debug against... stay tuned.

can you try with the java update that apple released on 9/24 and let me
know what happens? seems that fixed the other (related) bug.

Still broken...

As I'm probably in the minority (by a large margin) of users, I cant say I'm really expecting a
fix soon. I'm also starting to suspect that quicktime on my machine is wonky, because it
sometimes picks up cameras and sometimes doesnt, which is just weird.

Got it, will keep an eye on it and try to debug it once I have better
access to some serial devices.

please give this a try with 0149, it may be fixed.

Nope. Still sticks after retrieving the first (black) frame (ie: it is unable to read from the
arduino)

yeah, i had to back out the change for 0154 because of other problems that
were created. will keep working on it...

closing this bug, because we'll be replacing the current video library with
another sometime later this summer. as such, i won't be doing any more bug
fixes on the current video library. in the meantime, we recommend using
gsvideo, opencv, or one of the other video libraries that are available.