[chuck-users] HID, Seqs, Accessibility

Thu Mar 8 16:34:02 EST 2007

Kassen wrote:
[accessibility of the knobby panel UI]
> On 3/7/07, Veli-Pekka Tätilä <vtatila at mail.student.oulu.fi> wrote:
>> does that panel UI have the concept of keyboard focus, tab order and the
>> ability to interact with the controls using the same hotkeys for
>> knobs that Mac and WIndows use for sliders? THese are the most
>> frequently overlooked points in
>> synth UI design, in terms of accessibility, and make life hard if
>> your primary input medium is keyboard and output comes via synthetic
>> speech.
> I agree. A while ago I started covering my desk and USB ports with
> gaming devices and so I tend to use the keyboard for those things a
> lot more since there is no more space for a separate mouse :-)
I see, and most apps let you also move the mouse or send out keybord 
messages from gamepads, if all else fails. At .least the Gravis software 
does. ANother point is that some sighted folks don't like the mouse either. 
I do know people who positively hate drag and drop. Usability books also 
consider Uis that require right clicks, dragging or chord clicking as 
potentially unusable for new mouse users.

[uses]
> like you want it to work. It takes MIDI, HID and OSC so the sky is
> the limit.
Except that I don't seem able to clone my favorite Reaktor modules in ChucK 
natively just yet and have to hit the C plus plus territory for that, arrgh 
manual memory management be damned. I've been coding the last five years 
recreationally and so have had pretty much a free choice in terms of langs, 
apart from uni projects. SO I've grown to like the high-levle stuff, namely 
Perl and Java. So C plus plus is not my thing at all, if I can avoid having 
to use it, though Unix and C are a bit of an exception. THat's why I'm glad 
ChucK is what it is.

>> I've noticed that graphical programming, as in Reaktor, has a limit
>> after  which it would be faster and more natural to express those ideas
>> in code <snip>
> been with the Nord Modular since the beginning <snip> found that being 
> able
> to be very precise about the order in which things are computed is a
> huge benefit. That's not so easy to express in graphical systems.
That's right. Although you don't have parens in arithmetic expressions in 
modulars, as the signal flow determines precedence. Which reminds me how do 
ChucK and Nord Modular handle divide by zero? Most langs I know throw some 
sort of exception or call a signal handler. However, obviously the event 
divide module in Reaktor cannot simply stop processing at any point, 
especially in a live situation. I think IEEE floats have the types not a 
number and infinity so maybe dividing by 0 should give infinity, at least 
intuitively. Does ChucK support these special values?

> In Tassman I have at times run out of space on the screen in
> complicated patches.
At that point it is time to modularize. Kind of like the old programming 
rule of having a method or function limit of about an A4. IF it's longer 
than that, that's a bad smell. Of course, there are exceptional situations 
e.g. where avoiding the overhead of a function call is a major performance 
advantage.

[seqs]
Firstly about auditive interfaces.

> Yes, most obvious is things like Windows making a click sound when
> you click your mouse.
Totally pointless, at least to most people. But I've noticed after assigning 
different beeps for questions, warnings and notifications, that it is far 
quicker for me to detect what event it is based on a sound. i also tried 
samples of the screen reader saying the type very fast but processing that 
took a lot more mental CPu time. So I guess auditory icons might have their 
place after all.

> if the selected step comes up in the loop a click is heard in the
> main mix.
> This is a big help in programming beats while not having any
> visual feedback
Sure, sounds interesting. Which reminds me, I've used the Electribe range of 
hardware groove boxes and their lights and LCD displays are big enough for 
me to read, if I peer at the device closely. So I find the visual feedback 
of selected steps helpful in that context.

I also have an Alesis SR16 and in that counting steps manually, going in and 
out of the step edit mode to play is about as clumsy and frustrating as it 
gets. All context is dependent on being able to retain a consistant mental 
model of where you're going. Correcting a single live-input note timing in a 
pattern using such a system is wel, awful.

One thing I'd like is the ability to shift individual steps left or right 
one or more steps, while having a loop close around that point in the 
pattern. WHen I do use a step seq, which is not often, I tend to input half 
of the things quantized live, do som editing and add the rest using the seq. 
In that context I often need to wait for 16-bars to move a single note 
around only to find out that it needs to be shifted one or more steps still 
to arrive at the desired rhythm.

You asked about ideas. I like the fact that you can select a step for 
editing and if you hit a key at a time where there's no step, the next one 
will be selected. HAndy in deed.

Although it's not very accessible, I like the controls in Fruity very much, 
too. Rotating the pattern left or right is nice and there's a fill function 
which could be described as function fillNth(int startPos, int n) in ChucK. 
That's certainly cool and a real time saver even though I'm going to remove 
some of the notes it adds and add others, too.

In fact, I've been thinking of creating a Fruity inspired drum machine in 
some lang, which just might be ChucK:  IS there already sampler modules and 
the ability to layer and add basic effects to drum sounds without having to 
know DSP? ChucK could do the timing in this.

I also have the C64 SID chip on a hardsID PCI card and think it would be 
cool to use that as a drum machine. SO I'm thinking of creating a C program 
for editing drums in it on the C64 itself. But is it possible to call Win32 
DLL functions in ChucK? The HardSID has a Windows DLL interface for reading 
and writing the SId registers. In such use, having ChucK supply the timing 
could be a great benefit. If DLls are out what options do I have for 
inter-process communication within ChucK?

My last idea concerns the ability to enter notes from the keyboard. ONe of 
the things I hfind hard in step seqs, be it hardware, Fruity or something 
else is knowing which step is which as I cannot see them all in sufficient 
detail. That means I'll have to count, say to add a hit every 5th note or 
something.

And then it occurred to me. The function keys in a desktop PC keyboard 
already have gaps at 4-key intervals. SO Why not use them for randomly 
accessing steps as follows:

step key
1-4 f1-f4
5-8 f5-f8
9-B f9-f12
C-F print screen, scroll lock, break, and esc

> drawing blanks with regard to interface
> sonification for music programs. For video games it's a different
> matter, games like Rez and Luminess use this sort of thing all over
> the place to great effect but neither of those would be so much fun
> if you can't see well. Space Channel5 (by the same designer as the
> other two) should be playable with bad vision.
I'm out of the loop as far as new games go, so I'll use Wikipedia to find 
out more. It's totally OT here but incidentally I also have a long thread 
going regarding the accessibility of computer games for partially sighted 
folks:
http://www.game-accessibility.com/forum/viewtopic.php?pid=1044#p1044

[future]
>> I mentioned MIDI processing as one potential use and find the
>> current API a bit raw.
> It is. There have been more comments on this and that too is on our
> wish list. ChucK is a lot like Christmas for small kids; huge wish
> lists.
Oh yes, and a polymorphic Santa, depending on locale, <grin>. better play 
nice here so we might actually get some presents in a future release of 
Chuckmas.

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