Tom;<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If it were me, I'd make a new pair of rev/g in smack(), chuck the<br>
voice to it, then unchuck it on the way out. You're making shreds<br>
pretty fast so that may not lead to a script you can leave running for<br>
a long time, but it'd have the desired effect.<br>
</blockquote><div><br>I'm not sure about this approach. Reverbs are the very last thing I'd have a large amount of due to the processing involved. If at all possible I'd always try to deal with the issue by setting volume and mix. Clearly this isn't always a option for all reverbs; we may want to throw acoustic viability to the wind and instead deal with reverb as a per-voice parameter for a "purely synthetic" aesthetic.<br>
<br>It's a interesting issue; LiSa doesn't allow for per-voice outputs, nor do I think the ChucK architecture offers any options for that type of functionality; at least to my knowledge. <br><br>I'm not sure I understand the problem as the original post and code don't really go into what exactly Andrew is trying to do, making it hard to determine what the problem is, especially as I don't have a computer with a SMS (that would have to be a Mac in this context, I think) at hand.<br>
<br>I would think that any behaviour we care to define here should be available using one reverb and two instances of LiSa, on fed directly to the DAC and and one fed exclusivley to the reverb (which would end up at the DAC as well, of course), combined with LiSa.voiceGain(). Thanks to the build in reverbs being linear and time invariant we could safely use the two instances of LISa in paralel, in identical ways except that one would set the amount of straight signal for this voice, with the other setting the reverb level with no difference in the final result from using many reverbs summed.<br>
</div></div><br><br>I think that would deal with what I think the question is about but I may be wrong.<br><br>I'm not sure, BTW, why the SMS is polled in this way and not using "hi => now;", is there something speciffic about the SMS that is different from other HID devices that makes this preferable or is there some other reason to go for this method? I can see a possible need for a constant poll rate but I think that in practice data will still be quantised according to the buffer size? I may well be missing the reason for this due to not having such a computer here, just curious.<br>
<br>Hope that helps,<br>Kas.<br>