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.
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
[Quest for Fame V-pick] 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.
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,
[multiplexing] 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.
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
[back to your ChucK seq] 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 ...
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
Here's another mapping for accessing large patterns quicker: 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@mail.student.oulu.fi) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/