I'm pretty stoked about this. With all the hints I've picked up here I managed to make setting up a fiducial marker for the reacTIVision software a snap in PD. I made it a sub-patch/abstraction sort of thing I think. Sorry for the jumble there, I'm still not sure about what things are called.

To use it, dump this patch in your extras folder (or in the path somewhere) and when you want to track a marker, make an [rct_marker x] object in your patch with X representing which fiducial you want to track. The object will output, in order, Added, Removed, X-axis, Y-axis, and Angle. Added and Removed are bangs and the other three are floats.

Okay. I'm calm now. I love succeeding in these little tasks I set for myself.

Bill

PS: It just passed the "acid test", too. It tracked three markers at the same time with a camera set-up, not just the simulator. That was one of my other concerns.

http://www.pdpatchrepo.info/hurleur/RCT_Marker.pd

@obiwannabe said:

So the data is a set of distances between objects
on a plane (and their orientation?)

Yep. so you can chain a generator and an effect to the output, just by putting them on the plane.like this:

osc ------------ delay -------------- out (center of plane, represented by 0,0)

each module is represented by a marker on the table, and each one has 1 control (rotation: like a knob) + volume (determined by distance)

I've got this much done:

osc -------- out

with the rotation of the osc determining frequency, and the distance from the center determining volume. The subsystem for dynamically connecting things is in place (just send a float to fid-in like 5-in to connect to something other then 16: mainout)

@obiwannabe said:

With more than one occurance of the same symbol possible (or must they be unique?)

In the Tuio system, you can use fid (the number of the actual marker) or the individual id (sid or session_id) of the marker on the table. For performance, I didn't want to dynamically load/unload modules (it made it choppy) so I just went by fid, but you could use the sid, if you wanted to. I have no problem mapping hundreds of them at start time (in the main_snd and main_gfx parts) so going by fid works really well for me, and allows you to just map all the numbers that you have fiducials printed out for. Later, I could even read these mappings from a [textfile] but right now, I just want to get the logic worked out.

@obiwannabe said:

So you have the vetices of a fully connected graph of points
plus a rotation for each point as control data. Additionally each object
has a shape and the distance is between edges not center points
so an objects rotation affects its distance to all other objects
(or use perfect circles). Am I getting this?

Yep, I'm going by center point of the marker, so it's a circle. I'm using the coordinates to determine gain, so the further from center, the quieter. What I want is the same thing, but between individual markers. Right now, all the marker snd units have 1 ain and 1 aout, and if they are not effects, the 2 are just connected (I think it'd be cool to setup osc and phasor units that are normal, or ringmods depending on if they have audio input, but I need to work out distance logic, first.)

This might make a whole lot more sense if you download the thing, then download TuioCLient here and the reactable simulator here

Put TuioClient in your pd path (they have versions for mac, linux, and windows in the same file, I am using linux and mac)

Run the simulator (java -jar TuioSimulator.jar)

open my patches, and press the "0" connected to to start the graphics (in a window) I do it this way, so I can script it going into fullscreen (have a look at my shell script.) You can also leave it off, and just hear the sound stuff (without any graphic output) by not pushing the 0.

Move 16 (volume knob) onto the table area on the simulator and turn it. It will change the brightness of the center dot (to show gain) If you remove it from the table area, the gain will freeze at that level.

0, 4, 8, 12 are [phasors]'s
36,37,38,39 are [osc]'s

Put some of these on the table to hear them. you can get cool beating effects by moving a phasor close to the center, turning it so it slows to a click-beat, then putting some [osc]'s around on the table.

This is an example of what I've got so far. The reason all this is necessary, is that the reactable people haven't released any of the code they use to make graphics or sound, just interpret the actual camera data. I want to make a free, easy to use version, that does pretty much the same stuff, but on low-end hardware, all in pd, so non-opengl/dsp programmers can play with it.

I attached a screenshot of the gem window in Linux.

http://www.pdpatchrepo.info/hurleur/dktable.png

Sounds like you have things going really nicley. I'm not on mac/linux so I can't open your file. I tried uncompressing the .gz but the dktable file inside didn't do anything.

I don't quite understand all the parts you mentioned pertaining to routing, but I'm sure the patch would explain it more. I understand throw~ and catch~ but aren't getting a visual how this is working to route from one thing to another. For example if you only have an osc~ it'll go to dac~ and if there's two filters it'd go osc~ -> filter1~ -> filter2~ -> dac~ for example. Not getting a visual of how you're doing that yet. I'll have to reread what you wrote. How many fiducials are you currently using or setup for?

I may end up using reactivision to do some things on a multitouch screen I'm building. I'm probably going to do the visuals in processing, flash, or vvvv though. Do you know what software they used for the reactable? I can't remember if they said if it was all done in C++ or not.

There used to be a forum of ppl using puredata and reactivision (don't know if you were a part of it) but no one posts on it anymore. There were a couple examples on this website http://www.skanskgardsost.se/puredata/index.html, but nothing posted in a while.

@cerupcat said:

I tried uncompressing the .gz but the dktable file inside didn't do anything.

It's just a standard tarball (tar file, that is gz compressed) you can open them in Windows with 7zip (freeware) or winrar. I thought Winzip did it, too. Either way, I just put it in a zip file and attached it.

@cerupcat said:

I understand throw~ and catch~ but aren't getting a visual how this is working to route from one thing to another.

sound_base (in the zip) is the code that does the audio-routing. There is one in every module, and it just connects the throw~ to whatever number you send to it (16-in in this case) each module also has a catch~ that can be routed.

@cerupcat said:

For example if you only have an osc~ it'll go to dac~ and if there's two filters it'd go osc~ -> filter1~ -> filter2~ -> dac~ for example. Not getting a visual of how you're doing that yet. I'll have to reread what you wrote. How many fiducials are you currently using or setup for?

Well, that's the problem. I'd like them to just check if the center is closest, or some other module, but this requires that all the modules be checked on every update (unless there is some magic that has escaped me, which I don't doubt) I started working on the actual TuioClient, because it runs really fast in C++. But right now, there is no routing other then connecting to dac~. The patches I made illustrate a sub-system that could be used for more advanced routing, once I get the TuioClient modified (I think I'm close to finished with this part)

@cerupcat said:

http://www.skanskgardsost.se/puredata/index.html

That looks helpful. I couldn't get it to work (looks like I'm missing some stuff) but it looks interesting. I couldn't find the forum, but I will look at the patches.

@cerupcat said:

I may end up using reactivision to do some things on a multitouch screen I'm building. I'm probably going to do the visuals in processing, flash, or vvvv though. Do you know what software they used for the reactable? I can't remember if they said if it was all done in C++ or not.

I'm not sure, either. I know that the visuals were done in C++, but I'm not sure about the sound part. For my project, I'd like to keep it in pd, as much as possible, as I think it's powerful enough to do most things I want to do, while being really easy to work with.

http://www.pdpatchrepo.info/hurleur/dktable.zip

The new zip worked for me. Thanks! It makes a lot more sense now. I didn't get a chance to try it out with a fiducial or the simulator yet, but I will in a bit. I did look over the patch and have to look through the logic a bit more to understand it all. You have it nicely laid out though. I don't consider myself a programmer and am still relatively new to pd so it takes me longer sometimes to understand everything lol.

If you get the TUIOclient reprogrammed with the distance that would be awesome if you could share it.

I was doing things a little different when I began experimenting. I wasn't doing things relative to the center and instead did it relative to objects nearest. Since the x and y positions are always being updated and can just be stored until an object is used again; if an objects distance was less then my set proximity a trigger could then be sent to what you want. I only tried with 3-4 objects I think, so I don't know if this way is faster or slower than the way you are doing it. I'm sure your way is more efficient since you know considerably more than myself. I think there would be less routing the way you are doing it since the routing would ideally be routed automatically based on distance to the center; I don't think my way made it that far yet.

Oh, and I didn't post the forum link before because it's pretty much a dead forum: http://reactivsion.s4.bizhat.com/reactivsion.html

The link I posted is to one of the members of the forum, but his website seems dead too since there have been no updates, but he has a couple patches, including a GEM patch: http://www.skanskgardsost.se/puredata/index.html

Well if you ever need someone to test anything you're doing, send things my way.

I've used reactivision for a couple small school projects; a little music program and a game (nothing fantastic):

Here's another look at a reactable in action in a live setting. Originally posted on the reactivision forum at sourceforge.

@qbd said:

Here's another look at a reactable in action in a live setting. Originally posted on the reactivision forum at sourceforge.

Yeah that's a good video. I think there's a couple others on youtube also.

Did you ever get any farther with your tuioclient/puredata development qbd?

Has anyone made farther progress on this subject like a PD proximity patch for the markers, or a revamped C++ Tuio client?

only 2 years since the last post so surely something has happened for peeps since then!
I've been messing with the dktable patch and have found it very useful for understanding how you have used the fid ID's to trigger different elements of the patch. I am more interested in how I would go about assigning say 8 fids to different GEM visuals, how would I go about routing the 8 fid ID's to do that? would I edit the main gfx routing and ignore/delete the sound objects, and also replace the squares object to be whatever I wanted it to be such as a particle effect instead?

Hello,

Jean-Yves Gratius did a lot of work on using Fids in PD.
He did a great Abstraction pack called fid_abs.
you can get it here : http://jy.gratius.free.fr/

Regards,
xray303