[chuck-users] Seqs, Design and Usability (Slightly OT)

[Veli-Pekka Tätilä]

Kassen wrote:
> Veli-Pekka Tätilä wrote:
[usability]
> As a interface for musical programs I think the mouse has some serious
> issues in that normal mouse usage takes hardly any advantage of muscle
> memory at all. This closes the door on on many of the things we
> associate with becoming proficient (and expressive) with a
> instrument.
Hey that's something new I just have not thought about, thanks for an 
enlightening idea. Maybe that's why usability folks are not too happy about 
the trend of trying to look like the real thing in media players. Their 
basic point is that although match with the real world is a viable 
heuristic, that can be taken too far, too. TIny player buttons, knobs and 
sliders etc... are controls originating in the real World and made with 
human hands and limitations in mind. Yet the mouse, or any other pointing 
device for that matter, was never ment for primarily modifying such 
controls. That's just not very efficient and easy although it might be what 
your average musician, who isn't a computer power user and knows the 
harddware, has learned to expect.

For an example where real knobs shine, consider a knob that has a notch in 
the center so you can easily zero a signed parameter. IF it is well done the 
notch is prominent enough to make it easy to stop the knob yet is not on the 
way when you try to rotate the knob fast over a large range. Do any soft 
synths have such a feature? Rotating the knobs with the mouse lacks the 
tactile feel. ANother point, if you have to drag away from the control to 
manipulate it, it means a full-screen magnifier goes with the pointer and 
you have to relocate the knob every time to adjust it further. You also 
cannot follow its value or movment. So ffrom an accessibility point of view, 
thats
very very bad. For an emulation type in magnify in the run box, pick 7x 
magnification and after docking the magnifier at the botom, try using your 
favorite synth with the magnifier alone. The Os X magnifier is called Zoom.

Interestingly, here is what the Windows interface guidelines say about mouse 
operation:

Quote:
Providing a well-designed mouse interface is also important. Pointing 
devices may be more efficient than keyboards for some users. When designing 
the interface for pointing input, avoid making basic functions available 
only through multiple clicking, drag and drop manipulation, and 
keyboard-modified mouse actions. Such actions are best considered shortcut 
techniques for more advanced users. Make basic functions available through 
single click techniques.
End quote.

The Mac has similar conventions. But how many soft synths are usable without 
D&D (drag drop) and how many synth designers have education in human 
computer interaction?

> I think Space Channel 5 might theoretically be playable with no
> vision at all.
Interesting, I do know the ancient PC game quest for fame is. I'm able to 
play it using the 640x480 reso using the rhythm view that is. But that's 
seriously OT. Welll check out:
http://en.wikipedia.org/wiki/Quest_for_Fame

>> 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
> Interesting stuff! I'm going to read that and steal ideas! <grin>
Please do so we get better interfaces, though it wil probably take you n * 
1::hour to digest it all. The intro post is one of my longest.

[design]
>> 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.> That might also be a matter of 
>> getting used to ChucK. At first I
> often tried the known modular-system-style approach to any problem I
> ran into because that was what I was used to. In my own experience
> there are often other solutions that tackle problems in a very
> different way and end up looking more logical and simple.
So more like programming, well that's familiar territory for me outside of 
ChucK its just I've yet to adopt that mindset in ChucK. Well, could you give 
a concrete example?

Say I'd like to create a basic multiplexer for selecting OSc waves, one out 
of three. Here's the first way that comes to mind:

Have a Ugen reference named osc and chuck it to DAC. Then switch on the 
value of another variable using nested if else if else if constructs to 
assign instances of the different oscs on that ugen ref, to select that 
particular wave for output. Is that a good strategy?

What if I need to use a similar multiplexing structure in ten places in an 
instrument and also the amount of inputs and outputs varies? COpy paste is 
not an option, I'm unwilling to do that. Functions are not good enough 
either as they would need to retain state across calls. So as we don't have 
closures, apparently I need to create class files. Which brings me to my 
unanswered questions about where to put class files, how to import them in 
projects and so on?

[divide by 0 in modulars]
> In ChucK I simply avoid divide by zero
Well, let's test it:

C:\audio\chuck-1.2.0.7-exe\bin>chuck.exe CON
<<< "Die: ", 1.0 / 0.0 >>>;
<<< "I'm a survivor." >>>;
^Z
Die:  1.#INF00
"I'm a survivor." : (string)

C:\audio\chuck-1.2.0.7-exe\bin>

So apparently there's the value inf. But What's the literal value I use for 
comparing if something is infinite?

[seqs]
>> 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 agree, those electribes are a great example,
Although they lack the Fruity style auto fill and rotation functions, which 
I mentioend when you asked what kind of features would be cool in the ChucK 
seq. But they are simple yet sufficiently powerful devices

>> editing and if you hit a key at a time where there's no step, the
>> next one will be selected. HAndy in deed.
> I have something similar already but yes; that's a good idea.
One exception, obviously if you use a function for adding new notes, you 
Should be able to turn on silent steps, 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?
> Yes, there is. Our sampler is called SndBuf and it's quite good.
I'll read the manual more carefully, thanks. I hope it can mix multiple 
sources or if that's not possible, have multiple instances control playback 
acurately.

> easily use the way you address the SndBuf as a effect itself in the same 
> style as tracker users do.
So adding FX in the sample level, you know that could work. The major hurdle 
here would be the ability to use a common file open dialog or some other 
browser to add samples. OR a dir which is polled for wave files periodically 
and updates the samples used. Fruity's ability to auto preview samples in a 
pattern is a real timesaver and the same is true of the Forge open dialog.

>> 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 
>> <snip>
>> If DLls are out what options do I have for inter-process communication 
>> <snip>
> I would think MIDI would be the most obvious choice
It is but it is limited in terms of timing and range of parameters. YOu 
cannot use controllers to freely sweep the noise frequency with ease, which 
is trivial in C, especially on the C64 itself.

>> The function keys in a desktop 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
> He he he, Using the esc that way has a certain charm; it places the
> last step of the loop to the left of the "1" so that's quite natural,
> even if it does look odd.
I don't find it very natural myself, but at least it retains the gaps in 
intuitive places. It would be worse if esc was the first step. YOu could 
maybe also blink the numlock, scrolll lock and caps status leads for 
accents, portamento or whatever to indicate something about the current 
step. Idea stolen from MAME.

Here's another mapping for accessing large patterns quicker:
f1-f4 pick one of the four stteps in the current beat supposing 1/16 notes
f5-f8 select the beat in a measure supposing 4/4
f9-f12,esc pick the measure in a 4-measure pattern to edit
This is much like binary numbres in that the right-most digits, if we number 
bits in a little endian:ish way, control larger quantities.

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