[chuck-users] UI Idea and Accessibility, HID API and Bug?
vtatila at mail.student.oulu.fi
Tue Mar 6 06:14:48 EST 2007
[UI for synth panels]
>> in the future a sufficiently powerful, cross-platform toolkit for
>> effortllessly building synth panels as in Reaktor?
>I think the mini-audicle user-interface element thingies that are there on
>Mac right now and will be here for Win and Linux sometime soon-ish would
>come quite close to something like that?
Cool, I've only seen references to that Mini Audicle thing and tried out
some binary in WIndows. Itr looks to me like a ChucK IDE, though I've yet to
figure out how to run scripts in it, <embarrassed emoticon>.
>Reactor does and doesn't do there but I imagine that the more advanced and
>configurable it gets the less "effortless" it would be...
Yes, if these user interfaces are built programmatically, it would be quite
nice if the app could auto-layout panel controls for you. Alternatively,
I've grown pretty fond of the way how Gnome apps are able to build complex
layouts by nesting panels that layout their elements horizontally or
>> If it would also support presets,
>As soon as we get real file in-out you'll be able to make your own preset
That's right. Although I was thinking the panel objects could maybe export
their serialized state. That info could be then stored in a file directly.
Do chucK objects have built-in serialization capabilities as in Java? Or
maybe a class to inherit from and a bunch of callbacks for preset
management, kind of like in VSt plugs.
>MIDi learn,>You could already implement your own MIDI learn function for
>ChucK if you'd
Yes, although I'd have to ask the user which parameter should be learned, if
there are no on-screen controls to interact with. Is there any good way to
do string input in chucK? There's only simple unformatted debug printing in
>> respect user color and font preferences
>I don't think that would be one of the harder things to get but it might
>break some cross-platform compatibility
Not necessarily. I didn't mean the GUI would be customizable in the app
itself. In stead, it would use the colors and fonts you had picked for your
OS. I'm a low-vision user myself so I've chosen Windows colors that are
sufficiently high contrast but virtually no VST plug ever respects those,
>> keyboard and screen reader accessible, I'd be chucKed into virtual analog
>> heaven then, <grin>.
>Screen readers are aids for people with bad or no eyesight, right?
Basically yes. My rather technical definition is that they are apps that
programmatically reduce the graphical user interface to text, which is then
rendered as speech and or Braille. Other things they often do include
following focus changes, heuristically guessing which pieces of text are
labels and augmenting the keyboard interface by providing mouse-emulation
and virtual focus for apps that either lack a keyboard interface or have a
>languages as a musical interface might get around some of the limitations
>for visually impaired people caused by the recent developments in graphical
It's not so much the interfaces as such, but the fact that they are custom
controls screne readers are not able to read programmatically. They also
lack keybord access unlike say your average Office app. I'm actually a fan
of GUIs myself and wouldn't want to go back to a command prompt, though I
like programming. It's just GUis that don't cleanly reduce to text that are
the problem. Usually direct manipulation with the mouse, graphs and such. A
graphically editable envelope would be a good example, though again there's
no reason why the points could not be managed via a list view and some
Here's a quick experiment, if you'd like to know how using a basic screen
reader is like:
Hit windows+r for the run box and type in Narrator in it. If you are in OS X
launch VoiceOver and if it might be Linux run GNome and type in Orca in the
run box. Then turn off your monitor, unplug the mouse and starrt using the
computer relying on keyboard and speech.
>synth programs for people with perfect sight as well; it seems to distract
>from the sound.
Not to mention all the people with high res TFT displays, glasses and or
>Keyboard reading we have already
Yup, I've noticed. Although I think I found a bug in it. In:
The keystrokes get delivered to chucK even when that window has not gotten
the focus. I find that counter-intuittive and a potential problem if you
multi-task several keyboard instruments in different consoles. Sure it is
expected behavior for MIDI but not for the keyboard in Windows apps at
least. Besides such an implementation likely means system-wide Windows
keyboard hooks may need to be used, which can be a resource hog at times. My
screen reader already has its hooks in the chain.
How good is the HID API by the way? I've got a gamepad with a mini joystick,
a v axis, the throttle, pov switch and 6 buttons and hav always thought it
would be cool if I got it to send out MIDI. Also this laptop has a Synaptics
touchpad that can send pressure in addition to the xy coords. So I guess one
could use it as a 3D mini Khaos pad if you will.
With kind regards Veli-Pekka Tätilä (vtatila at mail.student.oulu.fi)
Accessibility, game music, synthesizers and programming:
More information about the chuck-users