<br><br><div><span class="gmail_quote">On 11/3/07, <b class="gmail_sendername">Atte André Jensen</b> &lt;<a href="mailto:atte.jensen@gmail.com">atte.jensen@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Kassen wrote:<br><br>&gt; SndBuf b =&gt; dac;<br>&gt; Envelope e =&gt; b.rate ;<br><br>That would be very nice indeed...</blockquote><div><br><br>I would be bouncing up&amp;down with happiness if we got this but there *must* be some catch. For one thing the whole &quot;pull model&quot; for samples would have to be re-written and we need some sort of protection against double connections to single parameters.
<br><br>&quot;b.rate&quot; above is probably just a single number but &quot;my_filter.freq()&quot; is a call to a more advanced function and running those, as we debated earlier in the topic, every sample will put a drain on the cpu and there I wonder how much cheaper a C++ implementation will be then a ChucK one.
<br><br>What we could also consider is enable the chucking of signals only to those member functions that cover for simple single values (with a cast to int where needed).<br>.<br><br>Kas.<br></div></div>