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

Michael Heuer heuermh at gmail.com
Wed Dec 5 16:01:55 EST 2012


Aurélien Bondis <abondis at kerunix.com> wrote:

> for part 1) I don't really know.

Yes, it is a problem.  Or an advantage, per your point of view
regarding Free Software.


> 2) don't know about it's future, but I just discovered it and found it
> really easy to use (for my needs), tried PD before but was too
> complicated for meeting. So I wish chuck to live long :)

I would like to see for ChucK an embedded library similar to libpd

https://github.com/libpd

I can only speculate that such already exists and is the audio engine
behind Smule iOS apps

http://www.smule.com/

Or perhaps the Smule technology is more similar to that of MoMu: A
Mobile Music Toolkit

http://momu.stanford.edu/toolkit/

In any case, Ge's colleagues and students are doing cool stuff.  :)


I would also want to integrate Audiobus for iOS; still waiting for
access to the SDK though.

http://audiobus.tumblr.com/


> 3) I use chuck on a Raspberry Pi. It works well but I'm not sure about
> realtime or anything. I was not able to make jack work with the RPi so I
> just use ALSA for now, so maybe more latency then possible.
> Archlinux for ARM has chuck ready to use for ARM
> procs. Also, I use python to make the bridge between GPIOs and send OSC
> events to my chuck running on localhost, had no issues.
> My whole thing uses 34MB of RAM and about 40-50% CPU, not realtime but
> responsive enough for my needs.

That is one of the best things I've heard.  Does the Raspberry Pi
support USB class audio in/out?

   michael


> On Wed, 05 Dec 2012, Rob Fielding wrote:
>
>> 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


More information about the chuck-users mailing list