pan caliente

im trying to use the data from the suddenmotionsensor of my mac to control audio.

when i do this there is like a crackle, that sounds like a problem of latency…

it gets better increasing the ms of the metro.

anybody had this problem and got a way to solve it without pushing the metro very high?

my system: macbookpro / 10.5.8 / 2.53 ghz intel / 4gb

im trying to use the data from the suddenmotionsensor of my mac to control audio.
when i do this there is like a crackle, that sounds like a problem of latency…
it gets better increasing the ms of the metro.
but its still there!

sudden-motion-sensor-performance-problems

You probably should interpolate between sms datapoints using line~.

i used rampsmooth~…didnt work…
i will try with line~

the problem actually is not the frequency of data change…

it is more activating the metro of sms. just the activation of sms causes the problem!

so it must be something with the cpu i think, it makes sudden changes from 0 to 32%, 0 - 23% etc.

is it so expensive to use the sms to control audio?

sorry, i forgot to say:
the problem actually is not the frequency of data change…
it is more activating the metro of sms. just the activation of sms causes the problem!
so it must be something with the cpu i think, it makes sudden changes from 0 to 32%, 0 - 23% etc.

is it so expensive to use the sms to control audio?


I think the key to this (what mzed was getting at) is that you need to interpolate "between" data points.

So if you're polling [sms] a certain number of times a second, your interpolation (line~ rampsmooth~ etc....) needs to be smoothing values over the same time period, or you'll get discontinuities.

Your ramp time for line~ needs to be the same as your metro speed.

With [sms] you're always going to get loads of jitter and will end up with either a smooth, unresponsive interface, or a very responsive one that warbles a lot. There will always be a trade-off between responsiveness, cpu hit and value smoothing.

Here's a thread which demos various smoothing methods:

https://cycling74.com/forums/smoothing-out-numbers

So if you're polling [sms] a certain number of times a second, your interpolation (line~ rampsmooth~ etc....) needs to be smoothing values over the same time period, or you'll get discontinuities. 

Your ramp time for line~ needs to be the same as your metro speed.  

With [sms] you're always going to get loads of jitter and will end up with either a smooth, unresponsive interface, or a very responsive one that warbles a lot.  There will always be a trade-off between responsiveness, cpu hit and value smoothing.

Here's a thread which demos various smoothing methods:
https://cycling74.com/forums/smoothing-out-numbers


but i dont know: i get always a crackle when a bang hits the sms, using metro or other ways to send regularly bangs…!?

so just making a polling, independent of the intervall, produces a crackle…!?

clicking the bang manually is no problem…

thx for your advices!
but i dont know: i get always a crackle when a bang hits the sms, using metro or other ways to send regularly bangs…!?

so just making a polling, independent of the intervall, produces a crackle…!?
clicking the bang manually is no problem…

You'll have to post the patch so we can check it out. I made a quick patch with [sms] as I was replying yesterday and got no crackles, but I deleted it :P

My first question is, how fast are you polling [sms] and how much cpu does the rest of your patch use? I didn't need to poll any faster than about 15ms to get a good result. And using a metro as fast as 1ms is never advisable. If you need it really fast, try using [qmetro] instead.

You'll have to post the patch so we can check it out.  I made a quick patch with [sms] as I was replying yesterday and got no crackles, but I deleted it :P

My first question is, how fast are you polling [sms] and how much cpu does the rest of your patch use?  I didn't need to poll any faster than about 15ms to get a good result.  And using a metro as fast as 1ms is never advisable.  If you need it really fast, try using [qmetro] instead.


but thank you for the idea with qmetro = no crackles.

actually for solving the problem i just tried with the sms, 1 metro (over 100ms) and 1 cycle~ in the patch…so really nothing!!!

something very strange…
but thank you for the idea with qmetro = no crackles.
i dont know!?

I just had a thought. If you turn off "Scheduler in Overdrive" and "Scheduler in Audio Interrupt" then you should be able to use metro with no problems. The metro speed at which you start getting drop-outs is also affected by your signal vector size, so raising that will enable higher speeds.

I just tried to write an explanation of exactly why this is and it wasn't very coherent. If another more articulate/better informed user than myself drops into the thread, I'm sure they will take a few minutes to explain it :)

If you're not needing [sms] to spit out data in a really timing-specific way then you should still use [qmetro], as it won't clog up the max scheduler as much as [metro] and will use less cpu.

I just had a thought.  If you turn off "Scheduler in Overdrive" and "Scheduler in Audio Interrupt" then you should be able to use metro with no problems.  The metro speed at which you start getting drop-outs is also affected by your signal vector size, so raising that will enable higher speeds.

I just tried to write an explanation of exactly why this is and it wasn't very coherent.  If another more articulate/better informed user than myself drops into the thread, I'm sure they will take a few minutes to explain it :)

If you're not needing [sms] to spit out data in a really timing-specific way then you should still use [qmetro], as it won't clog up the max scheduler as much as [metro] and will use less cpu.


thank you very much for your interest and help!

turning off "scheduler in overdrive" works, also raising the signal vector size. i was working with 256, with 512 no problem!

The SMS is quite a slow hardware call (if I recall correctly - I once wrote an external to grab the data myself and I think I found that it took quite a long time - comparative to what one might wish -to return the values when I timed it).

If the max thread is running in audio interrupt then when the max thread takes a long time to calculate it will stop the audio from calculating in time (because they are running in the same thread and one must finish before the other can continue) and you get a drop out.

Switching overdrive on means that the priority of events in the timing thread (anything after a metro for instance) is higher, so again there these events will compete more aggressively with the audio thread for CPU resources, which again may result in drop out.

If the max thread is running in audio interrupt then when the max thread takes a long time to calculate it will stop the audio from calculating in time (because they are running in the same thread and one must finish before the other can continue)  and you get a drop out. 

Sudden Motion Sensor = performance problems