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:
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).