[chuck-users] UI Idea and Accessibility, HID API and Bug?

Veli-Pekka Tätilä vtatila at mail.student.oulu.fi
Tue Mar 6 06:14:48 EST 2007


Kassen wrote:
[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 
vertically.

>> If it would also support presets,
>As soon as we get real file in-out you'll be able to make your own preset
>system!
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
>like to...
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 
the examples.

>> 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, 
for example.

[accessibility]
>> 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 
broken tab-order.

>languages as a musical interface might get around some of the limitations
>for visually impaired people caused by the recent developments in graphical
>interfaces.
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 
buttons.

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 
aging.

[HID API]
>Keyboard reading we have already
Yup, I've noticed. Although I think I found a bug in it. In:
.\chuck-1.2.0.7-exe\examples\hid\keyboard-organ.ck
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:
http://www.student.oulu.fi/~vtatila/ 



More information about the chuck-users mailing list