Tom; If it were me, I'd make a new pair of rev/g in smack(), chuck the

voice to it, then unchuck it on the way out. You're making shreds pretty fast so that may not lead to a script you can leave running for a long time, but it'd have the desired effect.

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. 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. 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. 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. I think that would deal with what I think the question is about but I may be wrong. 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. Hope that helps, Kas.

On Jan 5, 2009, at 2:36 AM, Tom Lieber wrote:

2009/1/4 Kassen :

...

I don't have a computer with a SMS (that would have to be a Mac in this context, I think) at hand. ... 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 think it's just to get the particular sound you get when a new voice is fired at regular intervals... I don't know what kind of noise he's recording, but when I tried it sounded kind of nifty. 'Cause his code differs from the example script he seems to have copied.

Technically its because the SMS interface on Mac laptops is polled, rather than interrupt-driven -- the Hid object in the case of the SMS won't actually fire any events. Also, polling it is relatively time- consuming. So rather than ChucK enforcing a specific poll rate, you can choose your own according to how expensive it actually is on your platform, how much CPU/sample you have to spare, etc. spencer

-- Tom Lieber http://AllTom.com/ _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Tom; Yeah, it's not always an answer, but sometimes it is! And it's easy.

So I try it!

:¬) I'll be sure to when there is a need. I don't think there is here, I think we can safely mix voices before the reverb instead of mixing 15 or so reverbs together, as long as we make sure all voices have the right "wet" and "dry" amounts. This will lead to slightly more involved control at starting sounds but it should be much cheaper on the CPU. If I understand all of this correctly saving CPU will mean running the whole thing at a higher rate.

It'd probably be similar to .chan() syntax.

Yeah. I'd like something like that; channels beyond .left() and .right(), they would be nice for this, for state-variable filters and perhaps even for modulation inputs.

I think it's just to get the particular sound you get when a new voice is fired at regular intervals... I don't know what kind of noise he's recording, but when I tried it sounded kind of nifty. 'Cause his code differs from the example script he seems to have copied.

I think so, I didn't know the SMS was so different; that's why I asked. Yours, Kas.