[chuck-users] embedding ChucK, and Windows8, ARM, etc.

[Rob Fielding]

I am using ChucK on an x86 based Windows8 large multitouch screen; as
nothing more than a way to create a multi-voice OSC synth that I can
describe to users how to install (at minimal cost) and get setup (with
little expertise on their part).  But Windows store apps (ARM, sandboxed -
like on iOS), forces generally conspire to have you try to embed everything
into a monolithic process.  So:

1) The GPL licensing (SuperCollider as well as ChucK) seems to be an issue
for anyone trying to host ChucK embedded into a controller process.  Is
this an actual problem, given that we are generally just linking in
unmodified build of the sources?

2) What is going on with the future of ChucK?  After tinkering around with
the options for making an OSC synth to match my controller: 1) visual
spaghetti code (Pd), 2) An ugly language in wide use (SuperCollider) 3)
Hard (CSound) 4) Nice but not well known (ChucK).

3) Performance.  I saw Ge Wang say that performance isn't a priority for
ChucK, but have no idea what the practical implications are.  Will there be
(and do there need to be) target specific optimizations to take advantage
of SIMD, and other ways of meeting performance goals, especially in the
more constrained ARM environments?

I haven't tried to do an ARM build of ChucK and get it installed onto
Surface, but I read that you can't in general freely communicate between
processes on localhost for store apps anyway (ie: OSC over UDP localhost);
so that leads back to the problem hosting ChucK as an embedded library.

-- 
http://www.youtube.com/rrr00bb
http://rfieldin.appspot.com
http://rrr00bb.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20121205/66ecf1ac/attachment.html>