[chuck-users] embedding ChucK, and Windows8, ARM, etc.
abondis at kerunix.com
Wed Dec 5 17:08:01 EST 2012
On Wed, 05 Dec 2012, Michael Heuer wrote:
> 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
> I can only speculate that such already exists and is the audio engine
> behind Smule iOS apps
> Or perhaps the Smule technology is more similar to that of MoMu: A
> Mobile Music 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.
> > 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?
I do use a USB sound card with it, a Behringer 302USB, it even powers
the sound card, which also powers the phantom power needed for my mic.
I get a good clear recordings, but for now I can't figure out
why the output has so much noise (sounds like it's picking some
interferences or clock or ...?). But the drivers are here yes, but
maybe not for all the cards :)
> > 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
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
More information about the chuck-users