event driven

RFID Audio Trigger

monkeeboy's picture

Hi all, I'm trying to build an install for an event that I'm running and I'm struggling to come up with a solution, I'll try my best to explain.

8 Screens looping videos with RFID readers attached 8 sets of headphones for people to pick up (colour coded) 8 RFID Cards colour coded to match the headphones When a delegate taps the RFID card on the screen, the audio from that screen plays in the headphones with the same colour code as the card.... and thats it!

I have access to an Echo Audiofire 12 and can use numerous desktops/laptops raspberry pi's etc, any suggestions would be much appreciated.

Thanks

Souped up Struct Environment & Structure Environment in Reverse - Obtaining all info in Macro with Structure Output Environment

Proposal: "get" objects that could get vertex/normal structure info post render/transforms/rotations, for Mesh/OpenCL based renderers, or even better, standard objects as well. In addition, other info about the state of the patches in a structure would be useful.

What could happen is that Render patches could get draped in an environment that's function is to provide a structure output with each Render patch inside of the macro being represented as a separate structure key in the output structure of the Environment patch.

The structure key names would correspond with each renderer's already existing key name (the one you see by hovering over the patch), enumerating structure by layer order of Render patches, with the post-render Vertex (and normal?) info of the Render patch enumerated nested inside of that keyed object. Again, this means the environment patch would convey the vertex and normal values post transform/rotate/scale on the renderer patch via a structure output on an environment that wraps one or more renderers.

Something like a clear, if on layer 1, would show up as index 0, with a keyname "clear", and possibly structure info that described the rest of the state. A Sprite on the next layer would be index 1, have a key of Sprite_1, info about the coordinates of each of it's corners, and perhaps all other info about the state of the patch.

By being able to easily obtain the vertex info of objects post scale/transform/rotation/render, we can create events that are dependent upon collision between objects, bar objects from touching one another, etc. In general, being able to read all info about the state of a macro via some kind of structure output on the macro just makes good sense, and it's sort of surprising that the functionality isn't there, after thinking about it - trying to do something ultra easy in another language tonight made me think of how this would allow for many different functions, and is a pretty straightforward and QC-esque way of handling it.

So, like a image broadcaster or spooky, but an environment that can hold consumers and have a struct output, that provides the scene structure with additional info provided by calcs of vertices, etc that the User gets to avoid (or have some real method of obtaining at all, really). This patch wouldn't "do anything", it would be for obtaining info.

ALSO, it would be great to be able to pass arbitrary structure data to a souped up GL Structure Environment that would work in a similar way (probably a separate patch). If wrote a keyed structure that corresponded with all of the Key names of the patches inside, as well as input key names, transmission could happen to those patches without even noodling anything up, if I plugged that structure into an input port on the Structure macro environment.

ALSO ALSO, iteration/duplication could happen inside of the environment by hooking objects that are like Iterator Variables to patch time on things, except the number of iterations would be specified on THAT patch, not the actual environment.

Perhaps one patch could perform both functions.