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
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
Kassen wrote: 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? 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@mail.student.oulu.fi) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/