OpenTSPS OSC data into QC

and relevant OSC structure info from one of the developers.. (quoted from openframeworks forum link above)

The messages are event based; so, to track each time something enters the field of view, listen for "TSPS/personEntered/"; to listen for objects as they move (which is I think what you're going to want), listen for "TSPS/personMoved/". Did you see the parameters in the src? The OSC message is structured like this:

0 - int - blob ID 1 - int - blob age 2 - float - blob center x 3 - float - blob center y 4 - float - blob velocity x 5 - float - blob velocity y 6 - float - blob bounding rectangle x (e.g. the top left corner of the blob) 7 - float - blob bounding rectangle y 8 - float - blob bounding rectangle width 9 - float - blob bounding rectangle height 10 - float - average optical flow at center x 11 - float - average optical flow at center y

if you are sending contours, the rest of the osc message is filled with contour arguments, starting at message[12] + message[13] and continuing until the end

12 - float - contour[0] x 13 - float - contour[0] y ...

hope that helps! basically, what we've done in the examples is a process like this:

1 - create an array to put TSPSPerson objects in 2 - listen for "TSPS/personEntered/" to add a new object to the array - keep track of the blob ID, x and y, etc 3 - listen for "TSPS/personMoved/ to update your objects - look them up in the array via their IDs 4 - listen for "TSPS/personWillLeave/" to delete objects from the array

edit: you can change the OSC host + port if you're having troubles. these variables are in the "communication" tab. here, you must set the IP address to the IP of whatever computer you're sending to (or to localhost if the apps are on the same computer), and the OSC port to whatever port your TSPS catcher is on.

brett renfer \ http://lab.rockwellgroup.com // http://www.robotconscience.com

I can get TUIO cursor data communicating. Looks promising!

thank you for introducing this sweet app. It looks like a very promising app indeed.

Regarding the OSC messages I'm having the same problem as you; QC only receives the data for one blob. Tried other listening ports but no result.

By the way one point about the TSPS/personEntered and TSPS/personWillLeave messages. These are also an array (floats) and not a boolean/float. So you can calculate from their first argument (ID) how many blobs are alive at a certain time (I did the calc in the attached comp) but unfortunately they don't work properly. for instance when ID=111 has entered the message still shows ID=109.

I attached a comp will calculate the Active IDs and will draw the points with a JavaScript patch ( it's a little less messy now :D ).

All in all I think we should draw the attention of the creators of TSPS to this thread and the QC community. I'm sure they can help us with the matter.(vvvv 1 QC 0 :D)

Thanks idlefon.. that Javascript is much nicer than my wall of structure indexes.. Ive found the personEntered data also a little hit and miss.. I tried using qcosc instead but it kept crashing and seemed to mess up the structure.. 'Ive chatted to Brett and pointed him to this post, hopefully we can all find a workaround.. Did you look at the processing example? all the data decodes perfectly, if you know your way around osc in processing do you think you could re-route the osc data from Processing back to QC on another port, in a keyed structure that we could iterate through when multiple IDs are present? (as is the case with TUIO examples from Reactivision: http://prdownloads.sourceforge.net/reactivision/TUIO_Quartz-1.4.zip?down...

qcOSC should work fine, but it was originally 32 bit - in 64 it will spin out.

If you fire it up in 32 bit, you can see why it's so handy; it can take structure in, and it can automatically make outputs when set to port.

qcOSC errors out for me with this app, requiring QC close/reopen. "no backtrace" among others. I'm running in 32-bit mode.

I know, I know I'm late :D Something came up and I forgot all about this post! but anyway:

Attached you'll find a processing sketch along with a sample .qtz. It "almost" works but acts a little buggy sometimes. The sequence should be performed as below:

1-open TSPS.

2- Run the processing sketch.

3- Open the .qtz.

Attention:

1- The processing sketch detects(thus sends) the blobs that are ENTERED after the sketch is executed.

2- Strangely when more than 3 blobs are detected the JS patch in the root of the comp won't work properly and will mix up data. I first thought it was the processing sketch but ckecked and found that the sketch is sending the right data (you can see that the sketch draws the OSC message that it's sending to QC and everything's fine). So probably the JS patch is screwing up.

I'd appreciate it a lot if someone could check the sketch and more importantly the composition to see if he can find any problem with it.

Idlefon this is great.. getting so close!

Yes the JS patch doesn't seem to be able to cope with the amount data when more than 2 or 3 blobs are detected. Even if you remove the iterator and just do the structure count it will crash QC above 2 blobs.

Could the structure reformatting be performed in the processing patch, and feed quartz a keyed structure.. like TSPS2Quartz/blob1/ TSPS2Quartz/blob2/ etc? then iterate through the keys in quartz? perhaps a separate structure count performed in processing sent out on TSPS2Quartz/blobcount/ ??

Sorry i can't be much more help...

I had a little play with this..

it seems the amount of data is too much for quartz osc to take.. i think its the osc plugin that is causing the crash. attached is a basic structure count which crashes when the count gets above the 300ish range.

I thought maybe if we limited the data to qc it might be enough to get bounding box information without crashing it.. which is a start..

I made a very slight edit to the pde to only pass the first 20 floats. From this I just took the bounding box data in QC.. So this now works very well as a blob tracker, I think that with a bit of work to the pde it might work with the contour data also.. it clearly just can't handle too many contour data points.

attached are the new pde and bbox qtz file.

For some reason it doesnt work in full screen mode.. unless another quartz window is open over it, like the patch inspector.. any thoughts?

Hey mattl!

Sorry I was absent a bit! Actually I was working on an interactive/digital theater project. Thanks for your valuable post I did all the interaction parts with OpenTSPS/QC. I'll hopefully write all about it on my soon-to-be-active blog (http://holescapes.wordpress.com/).

Now back to our problem here ;)

Regarding the OSC Patch problem, I think you're right. It's either slow, has message quantity limitations or both (maybe Cwright can clear this). I made what you suggested ( to send the blobs separately) and it worked flawlessly and that's exactly why I'm saying the OSC patch is the root of problems.

In the attached pde Processing is separating the blobs and sending them to QC. Since this method doesn't use OSC Patch to the send the whole data it works with big numbers of conturs. In QC you can have as many blobs as you like from the OSC patch (I made 10 for my example).

I also made a "BlobCount" message which states the Quantity of active blobs.

In your previous message you said one could "iterate through keys in QC". Could you elaborate a bit more about this.

Please check the comp and see if it needs anything else. By the way I can make some options for the processing sketch. for instance sending the biggest blob or Cropping the scene so only useful data are passed.

Cheers, Idlefon

Here's the pde with cropping enabled. When you run the pde it shows the centers of all the blobs and you crop the scene by making a rect with the mouse. Only the blobs with centers inside the rect are passed.

There is one bug though:

You must draw the rect from the up-left to the down-right vertex. I'll correct this ASAP.

oh wow this is fabulous idlefon.. thanks so much for figuring this out.. Cropping is very useful too, as there is no adjustment setting in opentsps, I was going to ask the developers to implement some basic features like this and mirroring the video.. I would love to see your installation.. I'll post more info on mine soon too, its just a fun motion sensing installation for children.

Regarding iterating through the keys, what I described to iterate through the blob1/blob2 etc wouldn't actually work, but you did what I was thinking..

What I had in my mind was that processing would send a structure with separate keys for each blob.. like TUIO data..

eg TUIO structure looks a bit like this:

0: (0) = 0: "c_id" = 1 1: "ypos" = .4 2: "xspeed" = .1 3: "yspeed" = 4: "xpos" = etc.. 1: : (1) = 0: "c_id" = 1 1: "ypos" = .4 2: "xspeed" = .1 3: "yspeed" = 4: "xpos" =

and you set the structure index, then structure key in qc to get the xpos for example. If you count the structure you can then set iterations for each.. but that is different to setting TUIO2Quartz/blob1 etc..

So the only issue I'm having is that the contour data seems to be limited to a certain amount of points.. whenever the blob contour size reaches a certain point size it stops and draws a straight line to the first point.. sometimes to the 0,0 top left corner.. I can't figure out if its a limitation of the kineme patches or if the data gets corrupted at some point or not through at all... see attached picture.. I tried previously altering the pde to send an oscBundle which seemed to help a little, but then was back to the same problem of only receiving one blobs data at a time..

are you having the same problem?

Preview	Attachment	Size
	hand.jpg	52.3 KB

attached is a qtz that highlights the problem.. it seems that the contour point data breaks down after about the 44th set of xyz coordinates.. interestingly this is essentially after the 100th float, as we are starting from 12 in pairs of two.. so im not sure why but it seems the pde data after the 100th float is corrupted..? or is it a problem with the javascript in QC..?

I have sorted the data into two streams, the first up to the 44th set of x,y,z, and the second from 45-100.. The points from 45-100 render in two sets of points only..

Hmm! You're right. It doesn't properly work for big blobs. I think the root of our problem is the JS patch. It seems it can not process fast enough.

I'm going to look into the possibility of doing all the calculations in the processing patch.

BTW the thing you mentioned about the TUIO-like data, OSC receiver can not accept 2D structures.

It will be nice if you could draw the creators of OpenTSPS to this thread. maybe they can help us.

I wish itsthejayj could guide us about his OSC plugin mentioned at http://kineme.net/forum/Discussion/DevelopingCompositions/OSCeletonwithQ... .

I think it may solve our problems.

Yea I couldnt figure out how to work this plugin either.. What is interesting too is that the data still crashes qcosc.. some different problems than the no backtrace/out of bounds (50).. such as errors saying that the blob0 port is already in use by the qcosc plugin.. etc..

if you analyse the data from tsps, you can see that it is sending several packets of blob data for each blob every time it sends.. so many packets for each blob at a fast frame rate. for qc purposes it only really needs to be one packet per blob per frame.. i think its just too much, i thought maybe the pde needs to be rate limited to only be sending one packet per frame per blob and ignoring the rest following.. do you think this is possible? I tried altering the frame rate prior to sending and though it staggers the data, it still sends multiple packets per blob each time it sends.. and doesn't help the problem..

The opentsps developers are aware of this thread, im hoping someone will jump in with a solution soon! ;)

Im not sure the problem is with the js patch.. if you limit the range to the data only above 100 it still only renders a straight line..

on the positive side I have found that the "kineme named struct maker" plugin will allow us to set a key for each blob message, then you can iterate through the keys.. it works but im having problems killing off the blobs when they become inactive.. the blobcount message doesnt seem to be working for me..? Ill post a qtz tomorrow..

getting closer!

What seems to be the problem ? The OSC label is a type of 'device id' its probably best to leave this blank. The discard excess messages port allows you to prevent flooding of osc messages. I just spoken to the company I use to work for who developed this plug in for me so hopefully we can get it open sourced for you guys to play with.

Hi itsthejyj.. the problem Im having with BBOSC is that I can't figure out how to get it to receive data at all... After setting the port number, Im not sure how to define keys/paths or what to do in the settings tabs with the various options for outputs.. What exactly is the "receiving path" for?
And how do you assign names for keys of floats, arrays, ints etc? any help appeciated. cheers!

Hi itsthejyj.. the problem Im having with BBOSC is that I can't figure out how to get it to receive data at all... After setting the port number, Im not sure how to define keys/paths or what to do in the settings tabs with the various options for outputs.. What exactly is the "receiving path" for?
And how do you assign names for keys of floats, arrays, ints etc? any help appreciated. cheers!

Definitely getting closer :D

You're right about the kineme struct maker. I had forgotten all about it. The iterations through keys is doable. I have the "dead blobs" problem too. I think it's the pde, I'll try to solve this ASAP.

What do you mean by multiple packets for each blob. The pde only sends 1 patch of data for each blob.

Hey itsthejayj! Thanks for stopping by!

Could you please post a sample comp which shows how to use BBOSC. I'd like to know if it accepts 2d Arrays or not!

Cheers!

Idlefon here is the key iterator.. the blobcount does work.. not sure why i couldnt get it to last time.. requires kineme structure plugin.. its a little bit flickery..

If you print(move); after all.set(j, move); you can see that for each blob it sends 2 packets of data for each blob before moving onto the next blob..I don't think its an error in the pde, I think this is the rate of data coming from tsps.

ie in this case id 1148 age 8 gets 2 packets before moving to 1150 age 8.. perhaps the second packet is what is causing the problem? ( This is just a wild guess really.. ) make sense?

[1148, 8, 0.93943805, 0.6130389, 18.815308, 3.5517273, 0.928125, 0.56041664, 0.0703125, 0.14791666, 0.0, 0.0, 0.971875, 0.56041664, 0.9375, 0.5708333, 0.928125, 0.59375, 0.9484375, 0.65625, 0.996875, 0.70625, 0.996875, 0.56041664]

[1148, 8, 0.93943805, 0.6130389, 18.815308, 3.5517273, 0.928125, 0.56041664, 0.0703125, 0.14791666, 0.0, 0.0, 0.971875, 0.56041664, 0.9375, 0.5708333, 0.928125, 0.59375, 0.9484375, 0.65625, 0.996875, 0.70625, 0.996875, 0.56041664]

[1150, 8, 0.9833881, 0.3493356, 1.1851196, 0.46591187, 0.9609375, 0.27291667, 0.0375, 0.13958333, 0.0, 0.0, 0.996875, 0.27291667, 0.9859375, 0.27708334, 0.98125, 0.29375, 0.9859375, 0.30625, 0.9828125, 0.32083333, 0.9625, 0.36875, 0.965625, 0.3875, 0.975, 0.38958332, 0.9890625, 0.40833333, 0.996875, 0.41041666]

[1150, 8, 0.9833881, 0.3493356, 1.1851196, 0.46591187, 0.9609375, 0.27291667, 0.0375, 0.13958333, 0.0, 0.0, 0.996875, 0.27291667, 0.9859375, 0.27708334, 0.98125, 0.29375, 0.9859375, 0.30625, 0.9828125, 0.32083333, 0.9625, 0.36875, 0.965625, 0.3875, 0.975, 0.38958332, 0.9890625, 0.40833333, 0.996875, 0.41041666]

[1148, 9, 0.95027065, 0.6141078, 16.176636, 1.1971741, 0.94375, 0.56041664, 0.0546875, 0.1375, 0.0, 0.0, 0.975, 0.56041664, 0.953125, 0.56666666, 0.946875, 0.5729167, 0.94375, 0.59166664, 0.9609375, 0.65208334, 0.99375, 0.6958333, 0.996875, 0.56041664]

[1148, 9, 0.95027065, 0.6141078, 16.176636, 1.1971741, 0.94375, 0.56041664, 0.0546875, 0.1375, 0.0, 0.0, 0.975, 0.56041664, 0.953125, 0.56666666, 0.946875, 0.5729167, 0.94375, 0.59166664, 0.9609375, 0.65208334, 0.99375, 0.6958333, 0.996875, 0.56041664]

actually maybe ignore this.. looking at the data coming into quartz it doesnt seem to be doubled up..

Hey mattl!

Check these combination. I think the "Dead Blobs" problem is solved. Don't know why but I feel it works more efficiently right now. please check the "big blobs" situation and see if the problem is solved.

cheers!

Hi Idlefon.. will this ever end? Ok I had a look at your new pde and qtz.. yes it does seem more efficient and stable.. unfortunately it still doesn't render big blobs correctly for me.. is it working for you?

If you set the qc viewer to "profile mode" you can see that at around the 100th float, the data gets corrupted.. lots of 0s and out of range floats. I imagine this is a bug in the quartz osc receiver, but it might be a problem in the pde, it seems unlikely though.

So my hack solution is to split the data in the pde into two streams, the first up to 99 floats, and the second 100 onwards. see attached edited pde and qtz. I made a slight adjustment to the js patches to compensate.. you can see when the float count gets above 100, the second stream starts to render in green.. so.. much bigger contours!

but when the float count of the second stream reaches 100 then the data gets corrupted again.. so at the moment the limit is 200 floats.

I would edit the pde to make it send more than two streams to increase the size of the contour, and alter the js patches to take several inputs and stitch the data together, but its a bit beyond my coding skills right now..

I edited the older TSPS_OSC_3 pde, because I haven't analysed your v4 changes enough to see exactly what is going on..

Preview	Attachment	Size
	iterator_split.qtz	13.82 KB
	TSPS_OSC_3_split.pde	4.59 KB
	hand.jpg	109.87 KB

made the split three ways. this allows at the moment for about 266 floats to pass.. i set it a bit lower than 100 per stream to stabilize it. This is enough for most big blobs.. perhaps not the most elegant solution but it seems to work quite well..

Preview	Attachment	Size
	Iterated_split_threeway.qtz	19.82 KB
	TSPS_OSC_3_split_threeway.pde	5.7 KB
	hands.jpg	75.38 KB

Brilliant mattl!

Finally it's properly working!! a nice workaround you managed there!!

I'll try to optimize the processing sketch and also implement the cropping and will post back.

Cheers again for your hard work mate!!

P.S: We should make a new thread concerning the OSC Receiver Bug to let everyone know this and also draw CWright's attention to this bug.

and cheers to you also.. we are definitely getting closer.. thanks for all your help on this. It would be great if you could optimise the pde, i think the newer v4 was significantly better as you mentioned.. and im sure my little hack wasnt so perfect.. i notice something wrong with the 3rd stream, sometimes is rendering random red lines.. and its still quite flickery the way I set it up.

As I understand it, the bugs with the OSC receiver are well known, its why hexler created qcosc. What is odd though is that qcosc is still crashing despite these changes, so Im not sure what the problem is with the data coming from the processing sketch.. maybe it needs to be rate limited.. I tried routing it through osculator and that accepts the data fine.. maybe both patches have limitations. Maybe Cwright or Hexler could enlighten us?

I'm well aware of a couple of the OSC bugs (I particularly remember the large structure problem, and I think I recall a couple others). :)

Finally the troubles are over and we've reached a working solution.

A big thanks to mattl for posting about this amazing software and mentioning the problems around implementing it for QC. Without his help and constant testing/revisions this was definitely not possible. So Cheers Mate! :D

For newcomers this is the instructions:

1- Install OpenTSPS(http://opentsps.com/).

2- Install Processing(http://processing.org/) and the amazing OSCP5 library (http://www.sojamo.de/libraries/oscP5).

3- Run the attached Processing sketch.

4- Run OpenTSPS.

5- Run the attached QC composition.

6- Click the mouse and drag it on the java window to draw a rectangular shape around the blobs you need to send their data to QC (The blue circles are drawn around the center of the blob)

A data sheet for the OSC messages sent to QC is available in the .qtz file(thanks to http://www.openframeworks.cc/forum/viewtopic.php?f=8&t=4285), So any manipulation of the data is doable.

We know that the QC comp and the Processing sketch seem more complicated than they should be but as you can understand from the contents of this thread, they had to be like this due to some limitations of the OSC Receiver patch in QC. If the limitations were hopefully sorted out in the future, we'll post a revised version of the combination.

Best, Idlefon

For some bizarre reason I can not edit my post above and attach the files. (it detects me as spam ;D )

So here they are...

Preview	Attachment	Size
	Final.qtz	18.25 KB
	Test.jpg	581.46 KB
	TSPS2OSC_CroppingEnabled.pde	5.14 KB

Hope it's sorted out soon Cwright!

We QC users are truly in debt to you and smokris and are thankful for your support!

BTW mattl!

Since we've finally sorted this out, I think it'll be splendid if you could tell the creators of OpenTSPS so the word "Quartz Composer" could be added to their list at their homepage :D

P.S: is it ok if I posted this solution on my soon-to-be-active blog (http://holescapes.wordpress.com/) ?

Amazing! Many thanks to you too Idlefon for your perseverance.. I'll let the developers know, or feel free to contact them yourselves. and of course please post on your blog as you like.. (no need to ask but thanks anyway ;)

Ive added in BBox and Blob info, centroid etc. see attached. Could probably be cleaned up a bit.. should mention Kineme structure tools and GL tools are required.

Idlefon.. so many thanks to you for your work on this.. I'll keep in touch with you regarding use of this software.. Im going to look into making use of optical flow and velocity data to enhance tracking and visual effects.. as well as collision testing (as mentioned in mesh thread..)

thx again!

Preview	Attachment	Size
	TSPS_all.qtz	35.84 KB
	bbox.jpg	141.64 KB

mattl that's great! Thanks for completing the .qtz !

Yeah, you're right! should have mentioned Kineme GL and Kineme Structure Tools. I guess I use Kineme patches so much that I was thinking they're a part of QC :D

I'll be more than happy to know about your ongoing projects mattl. Keep me posted then. Optical flow is a marvelous factor in TSPS. In my last project (Interactive Theater), I used this attribute a lot (for moving particles etc.)

BTW the .pde had a small bug which I fixed. Download it again from the post above.

mattl that's great! Thanks for completing the .qtz !

Yeah, you're right! should have mentioned Kineme GL and Kineme Structure Tools. I guess I use Kineme patches so much that I was thinking they're a part of QC :D

I'll be more than happy to know about your ongoing projects mattl. Keep me posted then. Optical flow is a marvelous factor in TSPS. In my last project (Interactive Theater), I used this attribute a lot (for moving particles etc.)

BTW the .pde had a small bug which I fixed. Download it again from the post above.

Hi again Idlefon.. Could I ask one last question.. (hopefully the last!) How difficult would it be to program into the pde, to force each blobs data to stay on the same set of 3 blob keys until it dies.. at the moment if I understand it correctly, when a blob dies, all the blobs of higher ID drop down to a lower set of blob streams..

what this means is that if you were to apply individual attributes to a blob when it enters the scene and moves around, when other blobs in the scene die, those attributes don't remain constant, they shift to other blobs as the key data moves.. for example if 3 people entered the scene and you called them 0=bob 1=peter and 2=jane.. , if peter left, then jane would not keep her name, she would become 1=peter, and the next person to enter would become jane..does that make sense?

Im thinking of perhaps doing this on the quartz composer side by checking a streams PID and then forwarding the data to a dedicated macro patch regardless of which blob keys its coming from, but am having difficulty getting my head around how this could be implemented..

I don't think any of this is possible using the iterator, but if ten separate macros were present it might be..

Any thoughts?

Hey mattl!

What you're suggesting is doable but needs some major changes in the Processing sketch since the OSC sending section is practically based on removing the dead blobs from the "all" arraylist.

If I fully understand what you want, we can implement a simple workaround for this. I can make a separate OSC message that contains the order of entered blobs with their IDs. For instance the message will contain:

0: 52

1: 55

2: 61

If you assign a specific attribute to the second entered person for instance, with a simple JS you can check if the blob being processed has ID=55 or not!

Do you think you can do with this?

Lets give it a try! I can see a way to use logic to check the IDs against the orderlist.. but yes a js would probably be better.. many thanks!

BTW.. I let Brett from TSPS (feedback@opentsps.com) know the patch is pretty much complete.. this was his response..

Great to hear! We'd love to add the patches to our Github codebase and our site. Definitely let me know when bugs are worked out. Also, if you could write a small readme to elaborate on how to string the patches together, that would be awesome.

I think its probably finished enough as is to give them.. what do you think?

Regarding the blob ID problem I mentioned I've been working on a way to isolate each blob by ID, by generating a structure of active IDs within qc, assigning them keys as they enter, and using sample and hold to keep them assigned to that key while they are still alive.. Its nearly working.. but still a bit buggy.. I'll post soon..

Shit mattl! I totally forgot that I should have made a revised .pde. can't tell you how sorry I am mate!! I'll get on it right away!

It's great to know that the TSPS guys have acknowledged us and what we're doing. I'll make a zip file with a readme and post it here first. If you confirmed that it's working without a bug, I'll send them the file!

Hi Idlefon.. no worries.!.. i had the compulsion to figure out a way to do it in the qtz.. and have pretty much figured it out, it seems to work fine but can't handle a lot of data.. It only really freaks out though when there are multiple blobs coming and going at the same time. it does i think open make it a lot more useful.. I'll post it tomorrow when i get it cleaned up.. Its enormously complex doing it in spaghetti code with logic.. I think I'll scream when I see how simply you do it with code..! thx again!..

have a look at this.. again probably not the most elegant solution.. much of the logic I'm sure can be replaced by some simple js patches but it works ok.. what it means is that each blob gets its own key and macro for its life, this will allow each blob to be individualised and collect and keep data, change states etc regardless of which osc channel the data is coming through. let me know what you think..

Mattl see if you can get anything out of this revised .pde . I couldn't figure out your .qtz ( I've caught cold and it has disrupted my concentration).

The .pde now send two extra data:

1- Active blobs' IDs

2- IDHistory: the order of blobs entering the scene.

I must say that the above-mentioned information are gathered REGARDLESS of the cropping area. So they are calculated for the whole scene. I will correct that as soon as I get a bit better (Health wise ;) )

Hi Idlefon.. hope you're feeling better! thanks the active blobs data is very helpful, it saves scanning all the indexes and building a list in quartz. Im not sure your intention for the IDhistory..

I'll try to explain what my logic macros do, maybe it will be easy to replicate in the pde.. if not its really no drama because the logic seems to do it fine.. but this is essentially what it does..

1) scan the index 0 of each data stream and build a structure of active blob IDs. (which you have done in the pde now)

2) assigns the active blob ID (index 0) as a structure key for each stream in a kineme named structure.. so the structure key for any blob data stream will always be its index 0 ID.

3) builds a structure of available ID 'slots" from 1-10. This is essentially just a structure with 10 numbers, 1 through 10.

4) When a new active ID gets added to the scene, it will take the first (index0) available number from the 'slot' structure, It sample and holds the slot number and the active blob ID together and sends the pair to a new kineme named structure, where the active ID is the input, and the slot number is the key. Once a slot number is assigned to an active ID, it gets removed from the slot structure, and remains unavailable until the blob dies, when it gets added back to the structure. ..

so for example.. ID 2345 enters the scene.. the first available slot number is for eg 4. it sample and holds these values and sends "2345, key 4" to the named structure. Slot number 4 is now removed from the slot structure until 2345 is determined to no longer be active, in which case it is added back to the structure of available slots.

So essentially what this means is that for the life of blob 2345, it will always have slot number 4, and number 4 will remain unavailable until it dies.. we can then use the key no 4 to make sure that 2345 is always sent to the one macro as a structure key. Because we assigned 2345 as a structure key in the beginning, it will now get the data of the same blob, regardless of which channel/data stream it is coming in from the pde..

I realise this probably makes no sense! but it does work.. and the logic to make this happen is quite complex.. mainly because it needs to constantly check whether a blob is still alive as the blob data moves to different streams from the pde..

make any sense?

Hey mattl!

I think I undestand what you're looking for. I made a modification to the .pde so it outputs this special data you want as well.

I really couldn't say it's the most-efficient way but it does the job(I think) properly. Just remember that the activeIDs and the blobOrder data is gathered for the blobs IN the cropping area.

"blobOrder" gives the order of the blobs entered. it's organized as below:

1- index 0

2- PID

3- index 1

4 - PID

.

.

.

If that specific index is not allocated to any ID, then the PID of that index equalls "-1".

See how it works for you!

BTW copy the 2 .pde in 1 folder and run "TSPS2Quartz..."

Mattl could you give me an update on this. Did it work properly for you?

Mattl could you give me an update on this. Did it work properly for you?

Hi Idlefon.. thanks for this.. I had a brief look a few days ago, looks promising! I just wasnt sure what all the extra data was on the blobOrder data was.. but I've been away since then, I'll try again tonight and let you know..

It works!! Brilliant! See attached qtz.. there is just a bit of logic to check that none of the Active IDs double up.. (it occasionally lists the same blob twice in the Active ID list very briefly) It creates a new structure and if it finds a double it removes it) The rest is just to make a clean structure with only the active IDs in the blobOrder list (any ID that is not reported as -1) feed these keys to each macro and other checks to disable blobs that have died and have frozen data in their structure. I haven't had a chance to test it rigorously but seems to be doing the same thing as my convoluted logic patches were.. You will see that each blob maintains the same ID and colour for its life..

thx so much for your help with this.. it seems a much more efficient/simple system..

Have a look and let me know what you think....

Brilliant mattl! Glad to hear it works ( I checked it too). This is actually a very smart thing that you went after (giving specific attributes to specific blobs).

I guess it's time to pack the whole thing with a readme file and send it to the creators of this lovely app to put on their site. I could do this if it's alright with you?

Yes.. please do.. glad its working for you too.. Cheers!

any news Idlefon? Didn't see it on github or opentsps site? Hope you are well! Matt

I have been reading this thread with high interest, as I am trying to develop an interactive magic forest floor (projector and Kinect high up in a tree).

Do I understand correctly that at the current stage of development, someone needs to be at the computer and select the blobs that will be used for subsequent processing?

I'm trying to get to a level where the forest floor can run, identify new people, etc. without any need to interact with the laptop (which will be hanging up there as well - out of the reach of party people).

If there's hope that we can get to that level, I'll totally dig into this. Is there any "most recent" version of this code?

Thanks so much,

Christoph

Hi Christoph, I believe the last posts with attachments are the latest stages of development. I havent tested this on mountain lion or latest versions of opentsps. However at the last version this was really a very sophisticated blob tracking environment, it ported nearly all the important data from opentsps including blob IDs, bounding boxes, and contours. From there you can program it to do anything you want with the data. We made a couple of floor projection inter actives from this, such as a painting interactive and another with interactive triggers on the floor. It takes a little setting up, but from there doesnt need an operator. happy to help if you have any questions. good luck

Hello! I've been trying to get TSPS data to communicate with Quartz Composer using Processing. I've looked at multiple iterations of the downloads provided in the thread, but haven't been successful in getting Quartz Composer to render. Basically when I render in QC, nothing appears.

I'm trying to just get the bounding rectangle data from TSPS into QC - I don't need the contour data.

So far I have all the Kineme plugins required. Processing detects the OSC messages from TSPS. The OSC Receiver signal reads true in QC - sometimes it flickers between false and true, but I'm guessing that's due to the noise in my TSPS settings.

Any help on this would be awesome. Thanks so much!

I like very much this discussion, it makes evident how collaboration works and produces, how fascinating and positive Web+OpenSource can be. And am grateful to the developers of this material.

Nevertheless, I also can't make it work. I tried with Processing 3, 2 and even 1. As the prior commenter, I just get no data. Am using not the first pde called OSC_Recieve (tells me OSCmessage does not exist), but the second one, TSPS2OSC, both libraries mentioned (not simultan), and several quartz patch options. In Processing I got log of OSC messages, but no data in Quartz. Am I doing something wrong?

Thnx again for that work.