[chuck-users] Controling Chuck - building accessible GUI
wheeler at kde.org
Mon Nov 19 18:37:45 EST 2007
Rich Caloggero wrote:
> Hey, just saw your blog and your XUL project, but didn't see any contact for
> you. So, glad you responded; thanx ...
> Anyhow, text only interfaces are inherently more accessible, but not always
> optimal for the job. What I am ultimately wanting is something like PD, or
> at the very least a good synth like dimensionPro which I can actually
> control in real time. I want to play with sound, not play with code!
> Last time I tried PureData, it was completely inaccessible to my screen
> reader. To make something accessible takes some planning (use the right
> toolkit and use standard widgets/components which have accessibility hooks
> already in them), and test with real users! For instance, if your going to
> use Java, then you either need to use Swing and its standard components, or
> write your own code to properly use the Java Accessibility API on your own
> AWT widgets (a fair amount of extra work so I've been told). Since most
> sighted software designers insist on creating their own widgets, accessible
> software tends to be hard to find, especially in music land.
You might give jMax  a whirl. It's in the Pd family and the UI is
implemented in Swing.
That said, doing sound design with jMax, Pd and friends is still
programming for all practical purposes. I ended up in the ChucK world
precisely because I find the interfaces of those programs to be
inelegant for programming (and I'm particularly fond of ChucK's timing
model). Most of the experiments that I've seen (including one that I
started) in binding ChucK to interfaces are mostly concerned with
providing a UI for interacting with ChucK programs, not supplanting
ChucK's logical building blocks. Were one to have that goal, I think
starting with the STK  (which ChucK also uses for a lot of the heavy
lifting) would probably be easier.
More information about the chuck-users