Hey Roald,

The sampling frequency for the sensors is as fast as it can be, depending on the hardware and the kind of data you're looking for. I don't have exact answers for you but we're talking about something on the order of 100 Hz for raw accelerometer data. Other sensor data may come in more slowly, especially fused data like orientation, which is calculated by integrating data from all three sensors (compass, accelerometer and gyroscope).

Touch data comes in more slowly, probably between 60 and 30 Hz. Not limited by the screen refresh rate, but limited by how much processing you're asking the iPad to do.

In all cases, I'd recommend using timers in Max to determine the interval between data packets. Hope that helps!

Thanks Sam. Yes I tried to use timer, but sometimes I got O ms as interval...

I've just tried to estimate the interval between data packets with different methods : jit.fpsgui timer cpuclock and..whoa ! there's something very weird ! the results are very different ! please open this patch and try it yourself...

looks like if data are received at a non-regular rate (have a look at your max window)

?

{ "version" : "Version 6.1.3 (69b6394)", "platform" : "mac", "arch" : "x86", "osversion" : "Mac OS X Version 10.8.4 x86_64", "samplerate" : 44100, "iovs" : 256, "sigvs" : 256, "scheduler_in_audio_interrupt" : "on", "audio_drivername" : "Core Audio", "audio_driver_subname" : "", "eventinterval" : 1, "overdrive" : "on", "mixerparallel" : "on", "mixercrossfade" : 0, "mixerlatency" : 30.0, "mixerramptime" : 10.0 }

Looks like once in a while packets are arriving at the exact same time, which causes two "events" to be processed one right after the other (within the same max "tick" in other words).

We could add timestamps for mira.multitouch and mira.motion events, which might help with working with that data on the Max end.

Indeed timestamping would be a great addition !