David: Thanks for such insight &amp; in-depth response. The points you&#39;ve made are being taking into concideration at the moment. &quot;Polling&quot; is indeed probably the term I was looking for, but didn&#39;t come to mind.<br>
<br>I suppose I should have shed light on the &quot;use-case&quot; a touch more in my initial question: Its for a live program where all processing is done in blocks. So no need for sample accuracy or any of that, polling is the winner :D<br>
<br>Re: Connection logic... I&#39;ve not yet decided how to approach this. Currently &quot;state&quot; is handled in each class, but this provides bigger problems: every parameter change needs to be passed to that class, and the way I have that implemented currently means about 6 function calls, and lots of array access... hogs up JACK cpu time and is inefficient.<br>
<br>Thorsten: Intresting read, I don&#39;t think FRP is a route I&#39;m going to take at the moment, as it would null all work I have done so far... but it did get me thinking in different ways :)<br><br>Jeff: Nice balance between performance &amp; flexibility. As prev noted, its a &quot;block-processing&quot; app, so I won&#39;t implement the audio rate controls. Never the less, thanks for the tip!<br>