[chuck-users] OT: Reader Internals, PD and Super Collider for Accessible, Conventional Modular Environment

[Veli-Pekka Tätilä]

Hi list,
This is getting OT,  so let's keep this on the list a minimal amount of
time. If you prefer to reply and only comment my bits, I recommend we go
off-list or snip maximally:

Changing quoting styles:
V, K, A = Veli-Pekka, Kassen, Altern 

Nord Modular:
K: did you hear about the Nomad project to build a open-source NM editor
in Java?
V: Nope, that's news to me. I took a look at both the original editor
and the Java version. Neither is really accessible enough for me to use
Nord as an accessible Reaktor substitute, though the Java version is
open source so that's doable. The original editor was better than recent
versions of Reaktor Accessibilitywise. MOst of the important, likely
custom  controls in the Java release didn't implement Swing
accessibility support, or at least my screen reader couldn't make much
sense out of them, oh well. 

K: have no idea how a screen-reader would work with visual cables
V: Depends, I use heavy full-screen magnification myself and the real
mouse for slow direct manipulation when I have to use it. Screen readers
normally follow control state changes and the keyboard focus, reading
the text, state and type of the focused control in this order, and
heuristically guessing labelness. There's a mode that logically iterates
all on-screen controls, say the MSAA control tree, regardless of their
WS_TABSTOP status, however, and in that mode called virtual focus, you
can drag and drop. So in Reaktor you go to virtual focus, arrow through
the screen logically until you find the right text output label, perform
a drag, arrow to the destination label (i.e. an input), and perform a
drop. The reader then programmatically simulates the mouse dragging and
dropping. Of course, domain langs like AT&T's Graphwiz, dialogs with
combo or edit boxes for connecting nodes, and tree-like editors such as
Treepad are far nicer and more efficient to work with compared to a
graphical tree, as far as screen readers go.
 
A: first you nee to create in supercollider  language a synthdef, just a
compiled crossplatform  description of connections of UGens in the 
supercollider scsynth. Once this is compiled you can forget about 
supercollider and the scsynth can load and control that synthdef.
V: Thanks for the summary, this looks like a good environment to build
on. However, it would still probably take a great deal of work, so if
there's an easier route, in terms of bad lazyness, I'd rather take that.
This talk abou the various synth environments let me reading up on Pure
Data PD, however. I seem to enjoy the philosophy and real time nature of
it, it is well documented and there's experimental VST support, too. And
I know C for the low level stuf.

The only major gripe I have is the graphical environment. The good
things are that it is easy to get started in, it uses standard menus,
and I can set up MIDi and audio graphically OK. However, most of the
panel widgets it uses and the graphical signal path aren't really
keyboard and programmatically screen reader accessible.

Given that PD is described as a data flow language is there a textual,
human readable and writable format, in which I could do PD patches
without the graphics? Put another way, what did the author use for
debugging before the GUI? At least there's some kind of exchange format
for Max. So I could probably write perl scripts around that, as a
desperate measure. Can I run PD on the command line as well?

Ideally I'd definitely hope there's a dedicated language, to which
format do the graphical widgets reduce internally, is there PD bytecode
like there's a virtual machine in ChucK? I've only done one course in
it, being mostly a usability guy and a bit of a computer scientist, but
i did circuit design using Altera's hardware design language, AHDL. That
is a dedicated language, the gist of which is to patch existing logic
components together which can also be performed graphically in an
editor. So something Altera like, with Perlish slices, Ruby:ish
anonymous functions and other goodies
would be ideal i.e. too good to be true. NOt to mention ChucKian time
handling, that's something I like very much along with the assignment
operator.

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