![](https://secure.gravatar.com/avatar/05744da049a193564578a6c1838ff374.jpg?s=120&d=mm&r=g)
right, single buffer, with multiple channels out => really lovely with hemispherical speakers and outside-in 8 channel systems. i think when i did this quite some time ago it was for a piece i was working on, and i hadn't actually meant for it to get checked in, due to the multichannel problems. i welcome any efforts to improve this, and thanks for taking a look Robin! it's possible the multichannel issues in Chuck have been resolved in the meantime, but if not, this may be a non-starter until they are. i wish i had time to work on this again, but i just don't at the moment. cheers, dan On Sep 7, 2012, at 10:38 AM, Robin Haberkorn wrote:
On 06/09/12 04:18, Dan Trueman wrote:
LiSa multichannel is for multichannel output. i haven't looked at it in a long while, as there were issues with the chuck implementation of multichannel stuff, and i welcome someone smarter than me to fix/finish it....
cheers, dan
Hi Dan,
apparently the LiSa buffer is still a single channel but you can pan the LiSa voices between the 8 output channels.
The reason LiSa is so slow may be that in its tick-function (invoked at sample rate for every LiSa in the graph), there are some loops over the 8 output channels and 200 (possible) voices even if it doesn't play or record or only one voice is used. Should have nothing to do with unnecessary function/method calls since they are inlined. Will have a look soon how to optimize that. Would seem plausible to me that only a requested number of voices is actually used and there should be a dynamic number of output channels (one for each voice). I don't think the latter is currently possible in ChucK. If nothing works I think I'll just patch it for my setup to use a single output channel and only one voice.
cheers, robin _______________________________________________ chuck-dev mailing list chuck-dev@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev