Suggestions Please: Unknown Amount of Users, [nodes] Proximity Regions
I’m working on a project, and it works but I feel as if I’m approaching it in a cumbersome manner.
What I’m trying to do:
I’m working on an interactive sculpture/installation where there are six speakers positioned in the center of a room. When a user approaches one of the speakers, their proximity affects amplitude and audio wickedness in M4L for each channel independently. To do this, I plan on using a ceiling mounted Kinect with blob tracking to determine the users proximity to the speakers within the space.
My Seemingly Flawed Approach (In Pseudocode)
My patch is attached pasted in this post. I based if off some of Lawton Hall’s patch where he used two separate [nodes] objects, and compared two zones to determine proximity. For convenience, I cut out all of the Kinect and M4L stuff because that’s not the issue. I also limited my patch to four potential users just for readability. I am using [nodes] because it is seemingly the simplest way to determine a set of XY coordinates proximity to a "center" point (i.e., the center of the zone).
In pseudocode my patch:
- Adds a new "user" zone for each blob tracked.
- Compares the "users" coordinates with relation to all the speakers to determine which speaker they are closest to.
- Determines which user is closest to which speaker, and prioritizes their proximity. For example, if two users are in the same speaker zone, it will prioritize the user that is closest to the speaker to affect the sound so that there are no conflicts.
- Plays audio representative of their proximity.
2) My current approach is "keep track of all of the blob/users proximity to all of the speakers" but I feel that it should be "have the speaker determine if there’s a user within its region and only pay attention to the closest one." Once again, I can’t quite visualize a way to approach it in that manner, especially if I want a more dynamic approach (i.e., just have blobs come in and sort which ever is closest to a specific speaker zone). Perhaps there’s a method I totally overlooked?
3) Is perhaps [nodes] just a cumbersome approach to this task to begin with? I tried to think of approaching it with multiple submatrices of the Kinect feed and averaging values, however, I couldn’t fathom a way to make it "proximity to center weighted" like the [nodes] object. I’m not the greatest at math, so if there’s an algorithmic approach that I totally missed, I’m all ears.
Any thoughts / insights / suggestions would be super super appreciated, even if it’s outside of my questions. If anything’s not clear just yell at me.
- This topic was modified 11 months by Duffield. Reason: I had issues pasting my code so I attached the file as of it instead