So here you might also be able to tweak things. * In OSCulator you can "smooth" the data. don't send ir data if you're not using it etc. I do have some recommendations that might speed up things though. I haven't had any issues with lagging as such.
If you experience any memory leak and can track it down, please let me know I'm getting really busy at school so i might not have so much time to look deeper into it the coming month. It should only be an issue inside the unity editor and not when you have a standalone application (hopefully ).
Osculator wiimote code#
I did make a fix that worked when running the code from a normal C# program, however unity doesn't seem to want to stop the thread. I have also tried to fix the issue with the thread not stopping in unity when you stop running the application. After having it run for a while i haven't experienced any memory leaks. I have been looking into it and i think i was too quick with regards to the memory leak.
Osculator wiimote Pc#
Its on my work pc which i cant access right now, so you'll have to wait for tomorrow.ĮDIT: Remember (and this is important) to have the same port number in the GlovePIE script AND in the WiimoteReciever script in Unity! otherwise you wont get squab out of it. That way, whenever you hit button A it will return 1.0, and if you dont it will return 0.0.Īnyway, to help ease things up a bit - if you havent figured it out by tomorrow i'll throw up my GlovePIE to Unity script which contains all that is needed for using all the buttons, pitch and roll and the XYZ (using sensor-bar) - so all you have to do is run it. In this case the data is sendt as a 1.0 - meaning it will always be true - we dont want that, so either directly link the button input through a Wiimote.A in glovepie, or store the data as a float in GlovePie using something like var.buttonA = wiimote.A.
Then in the Unity Oscumote part, you ensure that the port in the script is set to the same (in this case 6000) - what the code you posted yourself then does is check the "/1/" value - if its a 1 - then it has found wiimote 1 and will access the GUI parts and such to be displayed in Unity. So for instance, this following code would send a message to the local pc, on port 6000 - and indicate what it is: (Cant guarantee the caps is correct but you'll see if it works when you e.g. There's fairly small arduinos out there so it wouldn't be too big a problem if that's separate but if theres an all-in-one board that would be ideal.Basically what you do from glovepie is that you send out the following: It would be nice if the system was open to eventually allow for other sensors (flex/pressure etc.).Īre there any all-in-one boards that have accel/gyro/bluetooth built in? Or even further, accel/gyro/bluetooth/arduino?
I don't think I need an outrageous amount of information, particularly since there will be two of them (one per wrist). I'm thinking/guessing that Accelerometer/Gyro would give stable/fluid/precise readings of movement which can then be read/mapped in MaxMSP to process audio. From there, it's a matter of control and being modular. In looking around for sensors at Sparkfun there seems to be ooooodles of options out there. I'm messed around with a wiimote and MaxMSP (nothing too complicated), and I've messed about with Arduino+hardware, but never combined the two. I'm looking to build an embedded (in clothing/wristband) sensor system for use in a live painting performance.
0 kommentar(er)
