To explain the question:
 
I made a Reaktor ensemble that sends a low frequency sine wave modulation on, say, MIDI CC 55 and VST automation parameter 55.
 
I can send that sliced into event samples at varying rates - 50 times a second, 1000 times a second, whatever.
 
When I record the MIDI and automation data, I see the MIDI CC data looks very good, even at 1000 events per second.
 
But the VST parameter data recording is quite a bit less detailed, and looks terrible by example.
 
Naturally, I'd expect the MIDI paths in Sonar to be streamlined.
 
I don't know how to control the VST parameter control rate.
 
I don't know how VSTs decide to send such events, nor how Sonar frequently expects to receive them.
 
Does anyone know more about this?
 
Here are some examples of recording at 50, 100, 500 and 1000 events per second:
 
http://www.arachnaut.net/Reaktor/Automation/Automation50.png

http://www.arachnaut.net/Reaktor/Automation/Automation100.png

http://www.arachnaut.net/Reaktor/Automation/Automation500.png

http://www.arachnaut.net/Reaktor/Automation/Automation1000.png

Below is a relatively recent thread (2014) with links to some earlier ones.. I haven't re-visited this recently, but I think it's probably all still applicable:
 
http://forum.cakewalk.com/Automation-Write-records-inaccurately-m3040778.aspx
 
To summarize:
The minimum resolution that SONAR preserves automation nodes when thinning data written in real time seems to be on the order of 40ms, which is already twice the lowest rate (50Hz = 20ms), that you tested at, and seems to be consistent with your second screenshot. But there is also some logic around how fast the value is changing between ''samples', and when it's changing at rates that multiples of the automation 'thinning interval', you're going to get the kind of randomness and sync/phase error effects and variable time intervals that your screenshots show. Even understanding this, SONAR's thinning logic can be a little unpredictable
 
There is an AUD.INI parameter called AutomationDecimationMsec that is defaulted to 50 (ms), but according to comments by CTO Noel Borthwick in the older thread (2004) linked in the thread above, this setting is related to how data automation data are sent to plugins rather than how automation is thinned while writing it.
 
Ultimately, what SONAR records usually gives a reasonable facsimile of the original move when recording "real" moves made be hand from a control surface or with a mouse at the more gradual rates that automation is typically used. But when making extreme, oscillating moves to produce modulation effects, SONAR is not going to reproduce that well unless you draw the automation (or record CC data and convert it to automation envelopes in the case of MIDI).

In VST2 plugins parameter changes sent from the plugin are sent via the audioMasterAutomate opcode.
In VST3 this is sent via the performEdit API.
In either case these are treated the same as as user interface edits from the plugin. All edits sent to SONAR will be recorded accurately. However its possible that the plugin itself is sending the parameter edit data at a lower frequency that would explain your results. You could ask NI about it.

Thanks, that helps me understand.
I'll send a message to NI. I think Reaktor may send VST automation in it's GUI thread (25 Hz), but I'm not sure.
There's no user control in Reaktor for that that I know about.
 

Speaking with a developer from NI, it appears likely that the hardware automation is processed in Reaktor in the so-called GUI thread which runs at 25 Hz or thereabouts.