Monday, November 15, 2004

11-15-2004

Picked up a response this morning on the discussion board post:

extracting the matrix into indevidual values and then exporting it to flash
is the way to go.
i wasnt able to prase a message with more then one value in it to flash, but
something like
/xball_01 = 34
/yball_01 = 234
/xball_02 = 33
/yball_02 = 212
and then merging it in flash works, and might even be simpler then bringing
an array (=matrix) into flash and then spliting it into indevidual values.
anyways, i know of no other way to send multiple values to flash thru osc.
sorry for the lousy spelling.
post back if you find a way to send a couple of values as a single string
and then spliting it in flash into a nice array :)

So... he's mostly affirming my approach with the existing tools.

In the meantime, I tossed the Java Runtime Environment 5 on my machine and fired up flosc. Installation was *very* smooth and easy, no problems starting and running the thing either. So far, I've been able to connect to it from both EW and flash, and using the demo .fla file I was able to get the mouse coordinates to show up in flash.

I also figured out how to increase the number of inputs available on a StringToOSC or ScalarToOSC block, allowing me to bundle multiple data elements in a single OSC packet. I haven't found any naming options for them, but they do consistently come in in the same order. Besides, I can always concatenate some labels in front of the coordinate strings if this becomes a problem.

On to the bad news: even three tracked testing points were enough to gum up the system in sending out to flash. Tracking the test video runs this workstation's processor at about 65-70% capacity, if flosc is also running (which doesn't take much when idle). When flash is displaying the coordinate data as well, I can watch the processor usage ramp up to 100%, at which point the flash demo sort of gets "gummed up" and pretty much stops responding. It isn't a hard crash, though... if I stop EW, the system eventually catches up, though the data that streams out of EW seems to get lost. I'll have to do some more work to determine whether it is flosc or flash gumming up the works.

The best remedy I can think of is to relocate the flash client to another machine. All we have to do is point flash at the IP address of the flosc server and let it run. I think this would work well in the final setup too, because it means we could keep the bulk of the processing with the camera itself, and nothing more than an ethernet cable would need to run to the rendering system (or we could go wireless if we are feeling bold).

0 Comments:

Post a Comment

<< Home