Skip to content
This repository has been archived by the owner on Feb 27, 2020. It is now read-only.

Color control without disabling sphere tracking #25

Open
GoogleCodeExporter opened this issue Apr 20, 2016 · 1 comment
Open

Color control without disabling sphere tracking #25

GoogleCodeExporter opened this issue Apr 20, 2016 · 1 comment

Comments

@GoogleCodeExporter
Copy link

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

@GoogleCodeExporter
Copy link
Author

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant