<br><br><div><span class="gmail_quote">On 11/3/07, <b class="gmail_sendername">Atte André Jensen</b> <<a href="mailto:atte.jensen@gmail.com">atte.jensen@gmail.com</a>> 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>> SndBuf b => dac;<br>> Envelope e => b.rate ;<br><br>That would be very nice indeed...</blockquote><div><br><br>I would be bouncing up&down with happiness if we got this but there *must* be some catch. For one thing the whole "pull model" for samples would have to be re-written and we need some sort of protection against double connections to single parameters.
<br><br>"b.rate" above is probably just a single number but "my_filter.freq()" 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>