You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 27, 2020. It is now read-only.
Hello,
Hopefully someone is still checking these issues (hopefully it auto-emails).
Anyway, I have completed an OSC wrapper for receiving data from Move Me and
sending it to the program Max/MSP.
Now I would like to work on sending data in the other direction. The two
parameters I would like to control are rumble and color.
Rumble seems simpler - just send the request packet with the 0-255 value and it
should start rumbling at the level of that value. I had noticed however there
was a bit of a dead zone around values 0-60: You need to get above 60 for any
rumble, and in the other direction only 0 will turn it off - values in between
just seem to maintain the most recent rumble level.
But the trickier problem seems to be how to maintain control over the color
without losing sphere tracking. One workaround seems to be to accept the loss
and just use the handle data, but being able to compare handle and sphere
position/velocity/acceleration is a great redundancy I don't want to lose
unless absolutely necessary.
So, is the following feasible: ?
Writing a function for updating the color value, and then tracking the sphere
according to the updated color? I have a feeling this would be kind of janky.
Thanks for any advice to find the best solution. I had no idea that maintaining
a particular color was important for sphere tracking until I read Issue 12.
Original issue reported on code.google.com by kieran.c...@gmail.com on 11 Jan 2014 at 6:23
The text was updated successfully, but these errors were encountered:
Here's an updated version of the question after a little more code reading and
experimentation:
- Rumble is no problem, got it working, latency is a bit high though. Will look
for optimizations later.
- As for color, I can see the real issue is that I need to know the exact
relationship between the RGB values sent as 0.-1. ranged floats, and hues. My
intention is to force the Move to become a certain color, and then immediately
begin tracking the hue that corresponds exactly to that color. I hope to do so
in an "analog" way - i.e. I can make sweeps of colors that involve a constant
stream of changes to RGB values, and then be able to continue tracking that
controller as its color changes smoothly over time.
I am not certain if what I'm hoping to do is actually possible or not. Any
advice would be greatly appreciated.
Original comment by kieran.c...@gmail.com on 11 Jan 2014 at 7:28
Original issue reported on code.google.com by
kieran.c...@gmail.com
on 11 Jan 2014 at 6:23The text was updated successfully, but these errors were encountered: