Does JUCE have no support for sensors of mobile devices (accelerometer, gyroscope, proximity sensor…)?
I would think that many people developing musical applications would want to use such sensors to modulate sounds, affect velocity or pitch, etc. And of course it’s fundamental for games. It just seems such basic functionality.
Accessing the sensors is almost trivial on iOS with Swift, for example, but I have not found a way to do so using C++ (or Objective-C++). I have looked at the few examples in this forum, examined the way OpenFrameworks reads the sensors, etc., but was unable to figure it out.
Is there a way to access the sensors which is easy enough for a beginner to understand and implement?
If this is of interest to anyone, this is how I got the motion sensors to work under iOS. It has no dependencies so it should work even if you are not using Juce.
You must include the CoreMotion framework. If you are using Projucer don’t do so within XCode, because Projucer will overwrite your changes. Instead, add the word Coremotion in Projucer under Exporters → Xcode(iOS) → Extra System Frameworks.
Since CoreMotion should be turned on only when needed, do so with the start() and stop() functions. Also, create only one MotionManager object. Within iOSMotionManager.mm, set the update interval to whatever you need. According to Apple, their devices support at least 100 Hz.
I think it’s all quite self-explanatory, so here’s the code:
This is a sweet Feature Request (hint to convert your post )! Though I suggest stepping back to look at it from its whole because there are many more sensors available on mobile, both iOS and Android.
Yes, by all means! All of those sensors open up many posibilities. I’m sure that if they were easily available in Juce, people would come up with great ideas and completely unexpected ways to use them. They are great fun for sure
So, here is a very bare-bones way to access the sensors in Android. It’s surely far from perfect (no security checks, does not take the orientation of the display into account, etc.) but hopefully enough for people to get started and not have to waste too much time dealing with boilerplate. I just included a few of the many sensors and very roughly matched the values to the iOS counterparts. One difference though (which is purely the result of my inexperience) is that on my Android implementation you have to constantly call update() for the values to get updated (simply do so from within a timerCallback, for example).
Nice work! I wonder if it would be simpler to use juce::Vector3D (which I wish was part of the juce_graphics module instead of the juce_opengl module) for data type to DRY it up.
Thanks! I guess that depends. For what I am working on, having the values separately (not as a 3Dvector) is slightly more convenient. Of course, a proper JUCE class would ideally offer several different mathematical representations of the data, such as euler angles, rotation matrix, quartenion, etc.
Brilliant! I see that you added a Timer to not update the Android sensor elsewhere, as I was doing. Nice!
I had to add: #include “juce_events/juce_events.h” for it work in my configuration, but it all works perfectly.
Thanks for sharing!