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

[Veli-Pekka Tätilä]

Hi,
As you mentioned off-list some of the accessibility stuff is really OT here. 
SO I'll skip and snip more than usual.


Kassen wrote:
[usability]
> Fortunately a little more thought goes into DA controlls or drawig out 
> expressive modulations would be a total
> nightmare instead of a chore but I still think this a prime example
> of how ChucK can be used to make our own tools where the standard
> ones are lacking (see, not so OT at all!)
I agree, although some sort of a GUI would be nice, but I know that's on the 
wish list. Well, even if we ignore the controls, many soft Synth GUis have 
serious issues. I've seen some that have functions only in the right click 
context menu. Although I'm a big fan of context menus, it took me quite long 
to discover it in a soft synth. Again the heuristics here are that the 
right-click menu is a power-user feature, you should not depend on people 
using it and so the functionality should be mirrored somewhere.

>> 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.
> Some softsynths try to get close to something similar by automatically
> scaling the mouse sensitivity... That would lead to issues with the tablet 
> I experimented with
You mean a tablet PC, Yeah I can believe that. ANd how do you drag and drop 
with a pen interface anyway? I'm sure the screen reader mouse emulation does 
not like it, either. IT can drag and drop in software, but only if the 
source and destination show up as different focucible objects to the reader. 
Needless to say dragging an arbitrary amount away from the center of a knob 
canot be emulated with current reader software.

> The good news is that if you'd like to experiment with the mouse you
> can read it's raw data in ChucK using the mouse Hid. That will
> completely ignore where on the screen it is and allow you to link
> movement directly to sound which could be interestig.
Yes, especially as mine has got five buttons. YOu could make it modulate 
different things depending on which button or combo of buttons is pressed.

[Quest for Fame V-pick]
> I'd love to find that controller, looks like serious fun.
The game is great fun but the controller is not. It is plugged in the serial 
port and only transmits simple pulses when the pick is used. So I'd say it 
is about as good as a single keydown on the keyboard for control purposes.

[ChucK v.s. modulars]
> Generally with ChucK you depend more on modulations being based on
> time periods and much less on extracting info from zero crossings in
> controll signals. Another thing is that due to their structure
> multiple processes running in paralel on modulars need to be
> re-synced often (likely every cycle to avoid drift and edges arriving
> a fraction too early or late) with ChucK that's not nesicary and
> timing is much more dependable.
Yes, all timing is auto-synchronized to the sample the way I understand it. 
Still ChucK  does require rethinking common modular synth designs as you 
say, in terms of how to implement them.

> back and forth between audio and controll signals tends to be cpu
> intensive.
is there a difference? I didn't know that. I was kinda hoping I could use 
any audio signal for control or vice versa. Which raises questions like, how 
do you convert between the two and what's the event rate? I think the 
manual, though it has example code, lacks formalism in the style of say the 
K&R C book, of which I'm a big fan.

[multiplexing]
>> Say I'd like to create a basic multiplexer for selecting OSc waves,
>> 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
> Yes, i think so, particularly if you combine it with unchucking the
> connection. A array to hold the locations and a function that would
> take the one osc to be conected as a parameter could deal with it for
> you.
I see, I'l try something like that out. AS with so many other coding things, 
the best way to learn is to write and make mistakes, <smile>. But I've 
noticed that as a learner I usually like to start with a good book. In this 
case, the manual is far from complete, so looking at the examples is 
something I'll have to do eventually.

>> 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?
> You can have any number of classes stright in your file. If you'd
> like to import classes you'll need to make them public and put them
> in a seperate .ck file (one public class per file) and machine.add
> those before using them.
AH good info,, I think this will get me going, thanks. I read about class 
files but diddn't realize I could use the same add operation to include 
code.

[sequencer design]

[Electribes]
> and the MIDI implementation in braindead.
Yes, agreed. Anyone who claims that using NRPNs for about 50 parameters and 
only in 7-bit ranges is a good idea is, well, not wanting to make their 
interface musician friendly.  Controllers and multiple channels would do 
equally well with less overhead.

[back to your ChucK seq]
>> One exception, obviously if you use a function for adding new notes,
>> you Should be able to turn on silent steps, too.
> Yes, that's a area with big questions. I'm trying to make note input
> (with regard to timing) uniform with beats but notes have so many
> other properties as well that that sceme leads to exceptions in the
> interface. Ironing those out in a sensible way is a good way of
> losing some sleep <grin>.
Yes, and you might also want to add the ability not to quantize user input. 
The Alesis SR-16, whose step editing I already dissed, actually is one of 
the few drum machines which support both quantized and unquantized input.

>> 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
> Ok, yes, that would be hurdle but you can asign a key to reloading the
> sample you are using
Yes, that could work. Another thing I'm going to try at some point is tap 
tempo and then the ability to loop a portion of a song when you hit a key, 
such that you can determine the unit in looping, as musical time. I've 
noticed that when I use the software based volume control buttons on my 
laptop, Winamp playback studders in a cool and half-musical way. If only I 
could sync that and make the process more controllable ...

> 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
> Yes, makes sense but needs some thought.
This would be a  good way for selecting one step for editing or two steps in 
defining a range, even in a 4 measure pattern. But the downside here is that 
it is hard to sweep through say 10 steps. Where as you can use your finger 
to quickly sweep a range of buttons in a hardware machine or do a drag with 
the left mouse button in Fruity, to simulate that. But nothing would stop 
you from adding a func for defining two steps and filling the range between 
them.

> one of my prime demands is that it needs to be usable in the dark,
Which is interesting. ONe academic paper I read recently on accessibility 
said that in addition to aiding say people With no sight, accessibility also 
helps in special circumstances like smoky or dark environments. So here we 
are.

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