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:
http://cycling74.com/forums/topic.php?id=15180

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.

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.

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.

Alex