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
Kassen wrote: [UI for synth panels] 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.
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
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
[accessibility] 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. 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.
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
[HID API] 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@mail.student.oulu.fi) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/