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

For others who would like a quick example of qbd's patch, I threw this together (attached.)

I thought of some improvements, but to make it simpler, I just used your version.

It requires the TuioClient extension from the reactable site
It also uses hid math to figure out distance (to make it easier on me,) but I can replace that if someone needs it to be all pd math primitives.

Download the Java emulator off the reactable site, and play around with the markers.

Can anyone suggest a good method to find the closest marker?

Here is an example situation:

I have one marker on the table that is basically an osc~ controller (angle is freq)
when there is nothing else on the table I want it to connect to the center (output) but when I put a delay marker between the center and the osc~ I want it to connect to the audio_in on the delay, and connect the audio_out on the delay to the center (output.) In this way, you could make a chain, where each out goes to the closest in.

I already figured out distance to the center (see the attached example patch) but I can't figure out a good, efficient system for handling the process described above.
I think just 1 in, 1 out, is cool to start, but even that seems too tricky (and slow) with any of the ideas I have tried.

I wonder if I need to write it in an extension (just make TuioClient do more.) If I make the visuals in C++, I guess I should track distance there, because I will have to anyway to draw lines between markers. I'd like it if the pd stuff could do it all (gem visuals,) but I am worried it might not be fast enough.

If anyone has any ideas, let me know.

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

Hey Konsumer, did you ever do more with this? I was wondering if I could check out your improvements to qbs patch since you said you have thought of some.

I have a patch from a while back (which isn't very efficient yet) using reactvision and it detects the distance between two or more objects (not to the center point). Right now a toggle is turned on saying they are within the specified proximity.

I haven't had a chance to experiment with the best way to gate different controls/audio in different directions if they're close enough. Either using send/recieves with select objects or using spigots to turn on/off where a signal goes is probably the best way.

For audio, there's a spigot~ object (in extended version) that will change its signal to it's left or right inlet based on it's inlet. This could work for changing between two possibilities. If you do multiple spigots~ in series maybe this could work for an infinite amount of audio signals. Where you have the spigot decide where the audio needs to go and then send~ the signal to that place.

Send an osc~ to dac~ if objects not in proximity, or send osc~ to lop~ and lop~ to dac~ if they are close enough.

I already figured out the routing that was the easy part.

I just used a [throw~] that gets it's catch~ from a send (id-out) so to connect id 5 to main-out, which is 16 (the volume knob,) I just send 16 to 5-out. I have it sending 16 to all the outs now, on-load, but eventually I imagine that you could chain modules (whoever is closest to 16 is the endpoint.) This part works really well.

The problem I am having is that it's not fast enough to poll every single module on update of every other module. It makes the whole system herty-gerty. I feel like with some clever trickery I could be more efficient about it, but I just can't figure it out in pd-only. I was thinking I might need to modify TuioClient to get it working fast (maybe send a "who is closet to me" & "who is closest to center" message on update?

Here's what I have:

I just had some little ideas that make the logic a little smoother, and make it easier to just do graphics, or just sound, or add/remove definitions of instruments & graphics.

Just open main.pd to check it out. I included the shell script I use with it (in Linux) to start it up in fullscreen.

You will need hid_invert from the hid lib (should be in extended.) My example uses gem, and renders the graphic opposite for my projection system. If you want to change that, go into gfx_base and add a hid_invert between the receive and the math before it goes into translateXYZ. You could also just delete the main_gfx, if you don't want it to do gem stuff.

Marker 16 is the volume knob, and the others that do something are defined in the main_ patches in main (main_snd, main_gfx, main_network) right now it's all little white squares that are either osc's or phasors. You can see how easy it is to make your own, in main_snd and main_gfx.

The whole thing runs really fast and smooth on my setup.

http://www.pdpatchrepo.info/hurleur/dktable.tar.gz

@qbd said:

I think the best way to answer your questions is to direct you here: http://mtg.upf.edu/reactable/?software
Look around there and it should give you a good idea of what it's all about.

One appliction I see for the table is jamming with friends. Every marker can be assigned at least three controls for a synth. Everybody gets a handful of markers and you work things out together to make something happen. The videos linked to at the website show some pretty cool control schemes that I have no idea how to achieve, though. I could also see it being used for DJ'ing a live gig, especially tied in with video projected on a wall. Like I keep reading on the forums, "The possibilities are endless." Well, as endless as your imagination and programming ability.

Bill

Glad this got bumped.

So the data is a set of distances between objects
on a plane (and their orientation?) With more than one occurance of
the same symbol possible (or must they be unique?).
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?
Sorry if its FAQ, I didn't read as deeply as as I might.

cheers,
Andy

@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