Veli-Pekka Tätilä wrote:

Hi list, I'm new here. I'm a 20 something sight-impaired programmer and musician from Finland. I've got experience using analogs both virtual and real and know how to build Reaktor patches as well as program in Java, Perl and C. Now I've picked up the basics of ChucK and read through the PDF manual that comes with the program. Looks good and certainly a great deal more accessible than recent versions of Reaktor if you're using magnification and a screen reader program. I've got a flurry of questions I'll ask here.

ChucK says it is: chuck version: 1.2.0.7b (dracula) exe target: microsoft win32

1. What's the range of the audio float datatype and what would be the best way to detect zero crossings? My aim is to write a simple app that counts the samples in the low and high phases of a pulse wave and prints out the pulse width whenever it changes. If I can also get MIDi input into the app it would be quite easy to determine how pulse width in percentages changes as the function of the pulse width knob in my virtual and real analogs, whose exact values are not documented.

Here's some prototypical code (this is my first real chucK script):

Code: 100::ms => dur blockSize; // Processing resolution. until(adc.last() < 0) // Measure low-phase first. blockSize => now; // SAmple counters: 0 => int positive; 0 => int negative; while(true) { adc.last() => float sample; if(sample > 0) ++positive; else if(sample < 0) { ++negative; if(positive > 0) // Measured at least one cycle. <<< "Width: ", 100 * negative / (negative + positive) >>>; 0 => positive => negative; // Reset counters. } // else if // Ignore the pure 0 value. blockSize => now; } // while End code.

However, when I run this, the app doesn't ever seem to get past the until loop. I'm assuming here that samples are floats or doubles from -1 to 1 as in VST, as I didn't find the range in the manual. Is this correct? IF not, it's no wonder the code won't work, <smile>. Of course the rather grainy test processing rate, ten times a sec, affects matters greatly but I don't ever seem to get negative sample values even in arbitrary audio. The adc and dac modules do work. IF I patch them together and record from the wave input I get a delayed copy of the input in the output I guess this is the audio equivalent of "cat".

i didn't look too closely to your code but what you seem to have no statement like: adc a => blackhole; or adc a => dac d; at the beginning. so in fact adc isn't working at all because it's not in the ugen chain. best joerg -- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/

Veli-Pekka Tätilä wrote:

Hi, And thanks for an extremely quick reply. I'll snip myself here.

...

Veli-Pekka Tätilä wrote:

...

chuck version: 1.2.0.7b (dracula) exe target: microsoft win32 1. What's the range of the audio float datatype and what would be the best way to detect zero crossings? My aim is to write a simple app that counts the samples in the low and high phases of a pulse wave and prints out the pulse width whenever it changes. If I can also get MIDi input into the app it would be quite easy to determine how pulse width in percentages changes as the function of the pulse width knob in my virtual and real analogs, whose exact values are not documented.

Here's some prototypical code (this is my first real chucK script):

Code: 100::ms => dur blockSize; // Processing resolution. until(adc.last() < 0) // Measure low-phase first. blockSize => now; // SAmple counters: 0 => int positive; 0 => int negative; while(true) { adc.last() => float sample; if(sample > 0) ++positive; else if(sample < 0) { ++negative; if(positive > 0) // Measured at least one cycle. <<< "Width: ", 100 * negative / (negative + positive) >>>; 0 => positive => negative; // Reset counters. } // else if // Ignore the pure 0 value. blockSize => now; } // while End code.

However, when I run this, the app doesn't ever seem to get past the until loop. I'm assuming here that samples are floats or doubles from -1 to 1 as in VST, as I didn't find the range in the manual. Is this correct? IF not, it's no wonder the code won't work, <smile>. Of course the rather grainy test processing rate, ten times a sec, affects matters greatly but I don't ever seem to get negative sample values even in arbitrary audio. The adc and dac modules do work. IF I patch them together and record from the wave input I get a delayed copy of the input in the output I guess this is the audio equivalent of "cat". i didn't look too closely to your code but what you seem to have no statement like: adc a => blackhole; or adc a => dac d; at the beginning. so in fact adc isn't working at all because it's not in the ugen chain. Ah I see, only chains leading to DAC are processed to save CPU cycles. Somewhat counter-intuitive initially, in this case. I wish one could have

joerg piringer wrote: the ability to print out warnings about diagnostics related to disabledd modules. Most GUi-enabled modular environments show it in some way.

Seems my query is still valid, though. I added: adc => dac; At the top of the script and now I get an echo effect because there's plenty of latency between the input and output. It still doesn't get past the until loop, probably some other common newbie goof.

you can always use: adc a => blackhole; it routes the adc into nothing but still constructs a chain. but maybe that's not the problem. you can try to substitute your until-loop with the following: until(adc.last() < 0) // Measure low-phase first. { blockSize => now; <<< adc.last() >>>; } so it should print out the value of the adc. that could give you a hint... in my case it was always zero... but that's because of my soundcard settings on the laptop. best joerg -- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/

Spencer Salazar wrote:

On Mar 4, 2007, at 8:55 AM, Veli-Pekka Tätilä wrote:

...

Ah I see, only chains leading to DAC are processed to save CPU cycles. Somewhat counter-intuitive initially, in this case. <snip> Seems my query is still valid, though. I added: adc => dac; At the top of the script and now I get an echo effect because there's plenty of latency between the input and output. It still doesn't get past the until loop, probably some other common newbie goof. I believe this a current bug with adc (definitely not a newbie goof). My solution is something like this, although there may be better ways:

adc => Gain g => blackhole;

until( g.last() < 0 ) blockSize => now;

Let us know if that doesnt work! Ah it does, thanks for the correction. I think stuff like this should end up in the manual, as reading from the ADC is a common needd anyway.

WEll, here's an improved version which seems to measure PWM OK: adc => Gain g => blackhole; 1::samp => dur blockSize; // Processing resolution. until(g.last() < 0) // Measure low-phase first. blockSize => now; 0 => int negative => int positive; 50.0 => float width => float lastWidth; while(true) { g.last() => float sample; if(sample >= 0) ++positive; else { if(positive > 0) { // Measured at least one cycle. 100 * negative / (negative + positive) => width; if(width != lastWidth) { // Only print new widths. <<< width, " %", negative, positive >>>; width => lastWidth; } // if 0 => positive => negative; } // if ++negative; // Also the 1st sample of the next cycle. } // else blockSize => now; } // while I've also solved the mystery of the machine locking up when I run in a tight loop of 1::samp. WHen the script gets noise as input, as it does if I don't play anything, it tries to detect the noise pulse width too which may print out new values on almost every sample. That means thousands of print calls a sec. WIthout the Screen reader the machine doesn't really hault. But with it, the poor app tries to magnify and speak each and every print, though there's a bit of optimization, and thus leaves very little CPU time to other processes including chucK. Quite logical, actually. Is there a noies gate module? I should patch such a thing after the ADC to avoid the above situation. THere's also probably some minor logic error or else the waveforms I get in my synths don't cleanly match the sampling rate. That is I'm testing the script with the pulse waves from my Roland JP-8080 and Waldorf Pulse. In both cases, I get minor fluctuations in the output that happened pretty often. That is Sometimes the amount of negative or positive samples varies by one, even though I play one long static note and don't touch the width at all. Changing the pitch doesn't seem to eliminate the problem either, though of course the sample counts are different. I wonder what's wrong. Probably some classic off-by-one bug I've missed. Could the above code be re-written using the ZeroX module? I still am a bit unsure as to how it works exactly. -- With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/

Spencer Salazar wrote:

On Mar 4, 2007, at 8:30 AM, Veli-Pekka Tätilä wrote:

...

1. What's the range of the audio float datatype and what would be the best way to detect zero crossings? [...] I'm assuming here that samples are floats or doubles from -1 to 1 as in VST, <snip> Yes. Although, the -1 to 1 part isn't enforced within a UGen graph, Ah I see, so the rest of the value range is available when needed. But I imagine that if larger values end up in the DAC they will be hard clipped or wrapped.

...

3. Is there any way to decrease the latency on WIndows platforms for tru realtime MIDI playback and audio processing similar to Reaktor? You could try decreasing the audio buffer size through the -- bufsize### command line option (see http://chuck.cs.princeton.edu/doc/ program/vm.html for more information). Will do that. HOwever I just read that ChucK is based on SDL and DirectSound meaning a 20 ms latency is quite an achievement in many cards. It would be great if the WIndows port of SDL had native ASIo support some day. That would get rid of the latency issues with SDL apps in general.

...

4. How does one use the ZeroX module for detecting zero crossings? Quote: Emits a single pulse at the the zero crossing in the direction of the zero crossing Yes--this just means that for a zero crossing from > 1 to < 1 in its input, it outputs a -1 for that particular sample, and for < 1 to > 1, it outputs a 1. But what does it output when no zero-crossing is detected at the now time, which is more than likely? I suppose that would be 0 and could test, of course, but i'll be lazy and ask here.

...

6. How do you use the array datatype in ChucK as a hash? you can index the array with strings much like a Perl hash, except that numbres and strings are totally separate. If I get handed a hashtable whose keys I don't know beforehand, is there a keys or each function for iterating through the hash's keyset? The hash table form of arrays is somewhat limited in available operations at this time--its only possible to do assignment and lookup, with keys that are known in advance. Clearly we'd like to have some more advanced functionality built into hash tables in the near future. Ah I see, in addition to keys and values the ability to reverse the keys and values of a hash is sometimes very useful, though it only properly works if the values of the hash also happen to be unique. Still the current implementation can be used for light-weight struct:ish datatypes I'd imagine similarly to how one would use hashes in Perl in constructing classes.

I also read that the OOP stuff is a bit on the way. The lack of public and protected data doesn't bother me much but having constructor support would rock. As well as the ability to declare abstract or interface classes similar to interfaces in Java or pure virtual classes in C++. Which reminds me of yet another query, I read somewhere that as ChucK also supports multimedia, it would have OpenGl graphics support, too. Can I access it in chucK itself and if so, where's the reference? The manual doesn't say anything about openGl. -- With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/

Spencer Salazar wrote:

...

...

...

3. Is there any way to decrease the latency on WIndows platforms for tru realtime MIDI playback and audio processing similar to Reaktor? You could try decreasing the audio buffer size through the -- bufsize### command line option (see http://chuck.cs.princeton.edu/ doc/ program/vm.html for more information). Will do that. HOwever I just read that ChucK is based on SDL and DirectSound meaning a 20 ms latency is quite an achievement in many cards. It would be great if the WIndows port of SDL had native ASIo support some day. That would get rid of the latency issues with SDL apps in general.

ChucK does use DirectSound on Windows, which indeed makes attaining realtime latency problematic. ChucK isn't based on SDL, but rather on RTAudio, which does have ASIO support, though ChucK doesn't support that backend currently. So, ASIO is slowly making its way into ChucK, but we also don't have an ASIO platform to test on, making the process more difficult.

you could use asio4all http://www.asio4all.com/ is supposed to be working with all soundcards

...

Which reminds me of yet another query, I read somewhere that as ChucK also supports multimedia, it would have OpenGl graphics support, too. Can I access it in chucK itself and if so, where's the reference? The manual doesn't say anything about openGl.

OpenGL support (GLucK) is currently in development limbo, but its something we'd very much like to make available in the near future.

how about the possibilities to write extensions, so we could write our own? i know there's some support in the code but i didn't figure out how to use it. any hints? best joerg -- http://joerg.piringer.net http://www.transacoustic-research.com http://www.iftaf.org http://www.vegetableorchestra.org/

Veli-Pekka; I see, which reminds me of another thing entirely. Will ChucK have some day

in the future a sufficiently powerful, cross-platform toolkit for effortllessly building synth panels as in Reaktor?

I think the mini-audicle user-interface element thingies that are there on Mac right now and will be here for Win and Linux sometime soon-ish would come quite close to something like that? I'm not a 100% certain about what Reactor does and doesn't do there but I imagine that the more advanced and configurable it gets the less "effortless" it would be... If it would also support

presets,

As soon as we get real file in-out you'll be able to make your own preset system! MIDi learn, You could already implement your own MIDI learn function for ChucK if you'd like to...

respect user color and font preferences

I don't think that would be one of the harder things to get but it might break some cross-platform compatibility if people start referring to fonts that might belong to a specific OS in their ChucK files. and would be

keyboard and screen reader accessible, I'd be chucKed into virtual analog heaven then, <grin>.

Screen readers are aids for people with bad or no eyesight, right? That might be a interesting concept. It could be argued/ studied that programing languages as a musical interface might get around some of the limitations for visually impaired people caused by the recent developments in graphical interfaces. Might be a interesting point for Ge's research? Personally I'm very skeptical about the benefits of all those fancy graphics commercial synth programs for people with perfect sight as well; it seems to distract from the sound. Keyboard reading we have already, by the way, I'd say you are getting quite close to your heaven! Yours, Kas.

...

in the future a sufficiently powerful, cross-platform toolkit for effortllessly building synth panels as in Reaktor? I think the mini-audicle user-interface element thingies that are there on Mac right now and will be here for Win and Linux sometime soon-ish would come quite close to something like that? Cool, I've only seen references to that Mini Audicle thing and tried out some binary in WIndows. Itr looks to me like a ChucK IDE, though I've yet to

Kassen wrote: [UI for synth panels] figure out how to run scripts in it, <embarrassed emoticon>.

Reactor does and doesn't do there but I imagine that the more advanced and configurable it gets the less "effortless" it would be... Yes, if these user interfaces are built programmatically, it would be quite nice if the app could auto-layout panel controls for you. Alternatively, I've grown pretty fond of the way how Gnome apps are able to build complex layouts by nesting panels that layout their elements horizontally or vertically.

...

If it would also support presets, As soon as we get real file in-out you'll be able to make your own preset system! That's right. Although I was thinking the panel objects could maybe export their serialized state. That info could be then stored in a file directly. Do chucK objects have built-in serialization capabilities as in Java? Or maybe a class to inherit from and a bunch of callbacks for preset management, kind of like in VSt plugs.

MIDi learn,>You could already implement your own MIDI learn function for ChucK if you'd like to... Yes, although I'd have to ask the user which parameter should be learned, if there are no on-screen controls to interact with. Is there any good way to do string input in chucK? There's only simple unformatted debug printing in the examples.

...

respect user color and font preferences I don't think that would be one of the harder things to get but it might break some cross-platform compatibility Not necessarily. I didn't mean the GUI would be customizable in the app itself. In stead, it would use the colors and fonts you had picked for your OS. I'm a low-vision user myself so I've chosen Windows colors that are sufficiently high contrast but virtually no VST plug ever respects those, for example.

...

keyboard and screen reader accessible, I'd be chucKed into virtual analog heaven then, <grin>. Screen readers are aids for people with bad or no eyesight, right? Basically yes. My rather technical definition is that they are apps that

languages as a musical interface might get around some of the limitations for visually impaired people caused by the recent developments in graphical interfaces. It's not so much the interfaces as such, but the fact that they are custom controls screne readers are not able to read programmatically. They also lack keybord access unlike say your average Office app. I'm actually a fan of GUIs myself and wouldn't want to go back to a command prompt, though I

[accessibility] programmatically reduce the graphical user interface to text, which is then rendered as speech and or Braille. Other things they often do include following focus changes, heuristically guessing which pieces of text are labels and augmenting the keyboard interface by providing mouse-emulation and virtual focus for apps that either lack a keyboard interface or have a broken tab-order. like programming. It's just GUis that don't cleanly reduce to text that are the problem. Usually direct manipulation with the mouse, graphs and such. A graphically editable envelope would be a good example, though again there's no reason why the points could not be managed via a list view and some buttons. Here's a quick experiment, if you'd like to know how using a basic screen reader is like: Hit windows+r for the run box and type in Narrator in it. If you are in OS X launch VoiceOver and if it might be Linux run GNome and type in Orca in the run box. Then turn off your monitor, unplug the mouse and starrt using the computer relying on keyboard and speech.

synth programs for people with perfect sight as well; it seems to distract from the sound. Not to mention all the people with high res TFT displays, glasses and or aging.

Keyboard reading we have already Yup, I've noticed. Although I think I found a bug in it. In: .\chuck-1.2.0.7-exe\examples\hid\keyboard-organ.ck The keystrokes get delivered to chucK even when that window has not gotten

[HID API] the focus. I find that counter-intuittive and a potential problem if you multi-task several keyboard instruments in different consoles. Sure it is expected behavior for MIDI but not for the keyboard in Windows apps at least. Besides such an implementation likely means system-wide Windows keyboard hooks may need to be used, which can be a resource hog at times. My screen reader already has its hooks in the chain. How good is the HID API by the way? I've got a gamepad with a mini joystick, a v axis, the throttle, pov switch and 6 buttons and hav always thought it would be cool if I got it to send out MIDI. Also this laptop has a Synaptics touchpad that can send pressure in addition to the xy coords. So I guess one could use it as a 3D mini Khaos pad if you will. -- With kind regards Veli-Pekka Tätilä (vtatila@mail.student.oulu.fi) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/

On Mar 6, 2007, at 6:14 AM, Veli-Pekka Tätilä wrote:

...

...

in the future a sufficiently powerful, cross-platform toolkit for effortllessly building synth panels as in Reaktor? I think the mini-audicle user-interface element thingies that are there on Mac right now and will be here for Win and Linux sometime soon-ish would come quite close to something like that? Cool, I've only seen references to that Mini Audicle thing and

Kassen wrote: [UI for synth panels] tried out some binary in WIndows. Itr looks to me like a ChucK IDE, though I've yet to figure out how to run scripts in it, <embarrassed emoticon>.

Its easy! (hopefully...) You just have to type or paste some ChucK code into the editor window, start the virtual machine (Alt .), and then add the shred with Alt + . Once the virtual machine is active, you can also use the buttons at the top of the document window to add, remove, and replace shreds. We hope to soon improve the usefulness of miniAudicle by writing some decent documentation.

...

Reactor does and doesn't do there but I imagine that the more advanced and configurable it gets the less "effortless" it would be... Yes, if these user interfaces are built programmatically, it would be quite nice if the app could auto-layout panel controls for you. Alternatively, I've grown pretty fond of the way how Gnome apps are able to build complex layouts by nesting panels that layout their elements horizontally or vertically.

This sort of auto-layout functionality is planned, but for now manual layout is/will be required.

...

Keyboard reading we have already Yup, I've noticed. Although I think I found a bug in it. In: .\chuck-1.2.0.7-exe\examples\hid\keyboard-organ.ck The keystrokes get delivered to chucK even when that window has not gotten

[HID API] the focus. I find that counter-intuittive and a potential problem if you multi-task several keyboard instruments in different consoles. Sure it is expected behavior for MIDI but not for the keyboard in Windows apps at least. Besides such an implementation likely means system-wide Windows keyboard hooks may need to be used, which can be a resource hog at times. My screen reader already has its hooks in the chain.

This is actually a feature, not a bug. The idea is to abstract the keyboard as just some device with buttons, rather than a producer of sequential character input. Fortunately this approach doesn't require much in the way of system-wide hooks, as it simply uses DirectInput. As Kassen mentioned, there is the similar KBHit class available, which does require the ChucK window to have the focus and may be better suited to your preferred usage. There are a few other differences in semantics, such as key repeating when a key is held. See examples/event/kb.ck for an example.

How good is the HID API by the way? I've got a gamepad with a mini joystick, a v axis, the throttle, pov switch and 6 buttons and hav always thought it would be cool if I got it to send out MIDI. Also this laptop has a Synaptics touchpad that can send pressure in addition to the xy coords. So I guess one could use it as a 3D mini Khaos pad if you will.

As Kassen said, its definitely possible to use gamepads (see the hid examples), but ChucK probably won't be able to read the pressure of your touchpad at this point. thanks for your comments! spencer

Hey chuCK-sters -- One of the things I would argue for in terms of future UI development of ChUcK is to really chase after the idea of it becoming an 'imbeddable' library. People have different UI environments that are more or less congenial to work within, and the "let's bring it all into our OWN world!" just reeks of all that high-modernist totalizing that I hoped we were smacking down into a happy multicultural world. Software imitates life! Art! All that! One of the first things I hoped could happen would be a way to dynamically change parameters in an executing cHuCK script. I would love to have a ugen that would poll (or be notified) by the an 'external' environment that a new value was ready for incorporation into the chUcK VM, and then that value would be changed. For example, when I did the max/msp [chuck~] object, I would love to have had a way to set up a max/msp UI object to send values into a cHUck script like this: Maxconnection thing => feedback.gain => something.else; and have the executing script pick up any incoming values from the max/msp UI object dynamically. brad http://music.columbia.edu/~brad

On 3/7/07, Veli-Pekka Tätilä wrote:

Hi Kas and Spencer, As I wanted to comment both of your replies at once, I'm switching quoting style in mid-thread, IF this new one is problematic, let me know in a reply and I'l'll change back. AT least it makes it clear with screen readers who is saying what without having to parse "greater than x 3" in my head, <smile>. Feel free to snip heavily.

Very good!

V: Ah I see, sounds good to me. A classic accessibility question, 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 :-)

V: That's right, and also because sighted folks might like precise keyboard control from time to time. Precise adjustment of values, and the ability to type in values using numbers or modal dialogs would rock. I've seen a zillion synth UIs in which I'd like to type in an exact cutoff value and cannot, though I have 102 keys at my Disposal.

Indeed. Envelopes in Ableton Live come to mind.

V: It's funny you mention this. I didn't think of live performance when I looked into ChucK, although I imagine it could be of great value in that, too. As I input virtually everything via MIDI in my music, and record it live in a seq, the live aspect of chucK wasn't my cup of tea, though.

Well, livecoding aside ChucK can work as a live instrument exactly like you want it to work. It takes MIDI, HID and OSC so the sky is the limit. What

I'm looking for is a more accessible equivalent to Reaktor eventually, whose UI has been going down and down for years, in terms of accessibility. NAmely the ability to patch modular synths together and process MIDI eventes either in real time or off-lien in MIDi files like you would in Cakewalk application language. Another interest is as a simple testbench for audio and MIDi mangling ideas comparable to VST but much easier and faster to work with.

I think it will suit this role very well. I found development in ChucK to be very fast. MIDI file in and export aren't here yet but that seems like a useful and obvious future inclusion. 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, particularly if you have to use magnification and speech to begin with. Laying out math formulae as a series of modules is one obvious example. And another is counting stuff. To count a 16-bit integer quantity in Reaktor, I Would have to worry about the range of events and chain too binary counters together to get the precision. Where as in ChucK I can say: 0 => int myCounter; // And that's that. ++myCounter; // to increment, and modulo to wrap.

Yes, indeed. I have no experience with Reaktor but I've been with the Nord Modular sine the beginning, I personally 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. In programs like MAX it's implied in the layout but I'd rather use the layout to express something about the structure of the program which might not be the same intuitively all the time. In Tassman I have at times run out of space on the screen in complicated patches. [interface sonification]

V: I wonder if that's bene studied. As part of my Uni graduation stuff for investigating issues of current screen readers from the user point of view, which is just in its infancy, I've read plenty of stuff on accessibility. I do know auditory icons have been researched.

Yes, most obvious is things like Windows making a click sound when you click your mouse. However all serious DAW users turn that off for obvious reasons. I have never heard of interface sonification for musical effect in music programs beyond the metronome, Still, I'm finding the idea intriguing. Right now I have a prototype that works like this. In my sequencer you can select a step that you might want to add a beat or note to (or remove one from, etc). I made it so that if the selected step comes up in the loop a click is heard in the main mix. Since that already depends on the sequencer itself it's inherently quantised and I picked a click that suits the other sounds. This is a big help in programing beats while not having any visual feedback and it blends with the rest quite naturally, in fact I found my self "playing" those clicks already. I'm now thinking about ways to extend this and elaborate on it. I'm open for ideas here or links to research. Beyond organ players insisting on key clicks I'm 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. The Csound book has a interesting article on sonifying error messages in a way to indicate the sort of error or event that occurred, that's interesting too.

V: Quite nice, actually. But where do you store the sequences and in what kind of a format? The japanese music macro language (mML) would be especially nice for expressing modulation and monophonic parts in ASCIIbetical notes. I mean, I've used it to compose mini tunes for the 8-bit Nintendo on the PC. I still lack an official spec, though I've written a simple MML parser for myself in Perl.

Oh, they are just arrays. When loading the program these are empty; you have to play it to get something and it's recording or enjoying it while it's here because after you shut it down the music is gone forever. This is on purpose, actually, it's a conceptual thing. I've been called crazy already <grin>. I can store and recall a few patterns while it runs so it's feasible to write little songs in it.

V: But what kind of params would you adjust via timing? tap tempo comes very naturally but I don't know about the rest. Of course, switching patterns needs to be done in time, too.

Nearly everything, actually. For example; I have a "accent" function. Say I'm editing my leadline and I press the "accent" button that's on the Beatmania controller (a PlayStation one). The program will then wait for the next note of the lead line to come up and assign a accent to it. From then on there'll be a accent there. Of course more then that is involved but it all works in real time and it's quite fast (which it obviously needs to be for live song writing).

[MIDI] V: Lastly, some feedback about MIDI: 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. On the other hand there are free presents all round the year <grin>. Unless you are in Princeton, then it must be more like a experiment in stress management and sleep deprivation. Yours, Kas.

Quoting Kassen :

I'm not sure I understand how this would be different from OSC or MIDI.

It's kind of my whole point, in that it is a lot different (at least for me). This is from a draft article for Cycling 74 I'm just finishing: -------------- I'd like to make two final comments. The first is a plea to developers, and the second is a goad to Max/MSP users. For developers: think shared libraries and loadable bundles! The Soundflower routing for SC3 above works, but I would much prefer to access SC3 functionality directly from within Max/MSP. Or (for that matter) I wouldn't mind being able to access all of Max/MSP within SC3. The basic idea is that I like the tight-coupling that can be gained through the imbedding of one application directly inside another. I've used network approaches in other instances in the past, and although they work well for most situations, the ability to integrate control very closely can lead to much better standalone interfaces and applications. I would love to see the day when bringing in an external application is a simple matter of bundling it properly, finding the right entry-points, and then using the application completely inside an alternative development environment. -------------- OSC drives me crazy, by the way. brad http://music.columbia.edu/~brad

Quoting Kassen :

That sounds like something in the direction of SC3's client-server model with open communications between both. I imagine that if ChucK and MAX would also start doing things like that we would end up with a abstraction layer not unlike Xserver on *nix where you can pick your own interface and still deal with the same things, do I understand that correctly?

Not sure about that -- been awhile since I've done much X stuff. It's more from a developer standpoint. I really like the idea of being able to do something like this, for example: main() { ChucK *chucker = new Chuck(); chucker->doStuff(); ... chucker->changeThings(); ... chucker->takeOverZeeVorld(); } and just compile-in the chuck lib. Within whatever app your are developing. No messing with net setup, etc. brad http://music.columbia.edu/~brad

Quoting Kassen :

and we would all be very happy?

oh so very very happy! :-) And the world would be a better place... brad http://music.columbia.edu/~brad

Op 8-mrt-07, om 12:21 h

... using ChucK in non-OSS freeware are not permitted by the license. Honestly, this is probably also problematic for chuck~.

are you sure about that? general consensus in the maxworld seems to be that the gpl for externals is not a problem because max is an interpretor and doesn't not have to be free. this complies with what stallman says in prefering the gpl over lgpl. best isjtar

isjtar wrote:

Op 8-mrt-07, om 12:21 h are you sure about that? general consensus in the maxworld seems to be that the gpl for externals is not a problem because max is an interpretor and doesn't not have to be free.

No, I'm not sure. I've never looked at the license for the Cycling '74 SDK and I don't know if there's anything that has to be linked to or a rather small interface that just has to be implemented. But the interpreter point is irrelevant since the externals aren't written in Max. Max patches being GPL'ed is something rather different. I don't expect Ge & Friends are going to sick hordes of lawyers on Brad anytime soon, but just wanted to raise the issue as something for the ChucK to clarify at some point. And there are some things that I've toyed around with that wouldn't be possible with the current licensing. Note: I'm not trying to discourage usage of the GPL, but there are advantages and disadvantages to each of the different flavors of OSS licenses. -Scott (who decided to start dual licensing his stuff GPL/MPL :-) )

Quoting Scott Wheeler :

I've thought about writing a dummy VST plugin that just sets up the right connections and calls the ChucK executable with a given ChucK file.

I've made some pluggo plugins w/ ChUck that work well using [chuck~]. Fun stuff! I don't know much about the max/msp policy, but I think Cycling imagines it as a development environment and standalones/plugins are not covered by any Cycling rights-claims. There is a weirdness with Windows, if anyone is interested I recall some discussion in the archives. Also, apologies for not updating [chuck~] recently. As soon as the new version of cHUck gets set I'll get a new one out. Life intervenes... brad http://music.columbia.edu/~brad

garton@columbia.edu wrote:

Quoting Scott Wheeler :

I don't know much about the max/msp policy, but I think Cycling imagines it as a development environment and standalones/plugins are not covered by any Cycling rights-claims. There is a weirdness with Windows, if anyone is interested I recall some discussion in the archives.

I just grabbed the SDK and took a peek. It is definitely GPL incompatible as it requires linking to a non-OSS library. This isn't so much about the Max/MSP SDK license as the ChucK one. See: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation As such, chuck~ violates ChucK's license, not Cycling '74's. Again, I doubt the ChucK authors are deeply offended, but it'd be nice if their intent is to allow such things that such were made explicit. There are a number of ways to do that (the GPL provides a mechanism for exceptions, there are also popular more permissive licenses, the popular variations, in order of permissiveness being BSD, MPL and LGPL.). -Scott

On 08/03/2007, at 15.07, Scott Wheeler wrote:

I just grabbed the SDK and took a peek. It is definitely GPL incompatible as it requires linking to a non-OSS library. This isn't so much about the Max/MSP SDK license as the ChucK one.

See:

http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

As such, chuck~ violates ChucK's license, not Cycling '74's.

Then the consequence is, that no Max/MSP external can be GPL since they all link to GPL incompatible Max/MSP. Eh?

Steffen wrote:

Then the consequence is, that no Max/MSP external can be GPL since they all link to GPL incompatible Max/MSP. Eh?

Yes, basically. There is a distinction that if an external is created specifically for the Max/MSP SDK and does not use code from other GPL'ed projects, then there is an (arguable) implicit exception. But you can't (legally) take code from a third party GPL'ed project and use that either directly or as a library in a Max/MSP external. This naturally happens, but mostly because people aren't actually reading the license that they're using. -Scott

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/

Veli-Pekka Tätilä wrote: 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.

I think so, yes. With instruments I think it's worse then with media players. Media players tend to be switched on and left to run, maybe some tracks will be skipped, occasionally the user might rewind a interesting bit and late at night the bass might be filtered out on the eq. Instruments will be used in a more intensive way over a longer period. Fortunately a little more thought goes into DAW 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!) 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?

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 and I doubt your maginfier likes it. For general usage it might help.

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

Yeah... Once again the theory is there but practice is a sad affair. 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. Ignoring screen location might be a good thing if you have trouble with vision anyway. 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

Ah, that looks like Guitar Hero except without the focus on the usage of the screen. I'd love to find that controller, looks like serious fun. [ChucK v.s. modulars]

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?

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. Even in digital modulars (the Nords, Tassman, likely Reaktor and MAX as well) vertical flanks will always be quantised to the sample rate which can and will result in issues with timing and execution order. That's the main thing, for me. On the downside: in ChucK going back and forth between audio and controll signals tends to be cpu intensive. I'd still like a way to generate events based on zero crossings without needing to use a if-then loop based on ZeroX.last() at a rate of 1::samp because those loops are so expensive. [multiplexing]

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:

<snip> Yes, that's a good example. On thing you could do is create a array and asign different osc's to the locations in it. Even if you don't use that for adressing you could use the ChucK and unChucK operators to connect and disconnect the oscilators. The advantage of that is that ugens that don't end up at the DAC (inderectly) or blackhole won't be computed which will save cpu. That's of cource quite different from a normal multiplexer in architectue but for 3 osc's it will save you about 2/3 of the cpu time which is quite good and not something that a Nord Modular could do. Admittedly the NM has real wave-form switching so in this particular case it's moot. 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?

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. The two of those could be made into a class if you'd like to use the same thing a few times. 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?

Arrays, I'd think... That would depend on the exact needs. Which brings me to my

unanswered questions about where to put class files, how to import them in projects and so on?

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. This is dealt with in the manual and examples. It's not a 100% without issues yet but that would be the way to go about it.

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

I have no idea, never ran into that. Ge or Spencer will know. [sequencer design]

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

Well, and cheap and cheerfull. They have some very good interface ideas but the channel-bleeding on the outputs of mine is atrocious and the MIDI implementation in braindead.

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

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.

You can have both and indeed; the manual and the examples will help there. I warmly recomend editing/recombining and remixing the example files for aspirering ChucKists.

So adding FX in the sample level, you know that could work.

Yes, infact some of the basic otf example use sample-retrigering from drum rolls. This is quite easy to do. 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.

Ok, yes, that would be hurdle but you can asign a key to reloading the sample you are using if you'd like to have a wave-editor next to ChucK. Auto-scanning a directory isn't going to work just yet. [sid]

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.

Then I suppose the only option will be adding a bit of C like that and recompiling.... 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.

I'd like that too. I think a HID-out that could do that is on the list as well. 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.

Yes, makes sense but needs some thought. Because I like to play live one of my prime demands is that it needs to be usable in the dark, after drinks and under stress. Yours, Kas.

Veli-Pekka Tätilä wrote:

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

It all kinda interacts. I imagine there must be more people who want to put ChucK in clubs.

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.

I think you can seriously wonder how suitable sub-menus are for instruments at all. Verious synths -including ChucK if we look at programing and using the HID/MIDI/whatever a seperate- use two different interfaces for configuring and playing. It gets more tricky with pro-level keyboards and grooveboxes and so on. I don't think sub-menus are such a good idea there. Generally I think many instruments would be better with less but more carefully planned out features. The piano lasted centuries already; I don't think the mc303 will. Acessibility and playability have a huge overlap. You might find this PDF worthwhile, it's by ChucK co-author Perry Cook and on basically this topic; http://soundlab.cs.princeton.edu/publications/prc_chi2001.pdf You mean a tablet PC, Yeah I can believe that. Actually I meant one of those graphic designer tools to replace a mouse with a pen and use absolute (not relative) controlls. I had hoped the absolute desk-screen mapping would make me faster thanks to muscle memory but instead auto-scaling resulutions made it very unpleasant affair in Ableton. ANd how do you drag and drop

with a pen interface anyway?

Exactly like with a mouse or with a chopstick on a dinner-plate. <grin> That's not the hard bit, asuming you are used to a mouse 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.

That would probably mean the same effect would be seen when drawing envelopes.

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.

There are some examples here; http://smelt.cs.princeton.edu/ [Quest for Fame V-pick]

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.

Oh. Right. That's disapointing. I had hoped it would be based on tilt/ inertia sensors. [ChucK v.s. modulars]

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.

Exactly. Sticking to "modular tactics" will lead to ugly code and much cpu overhead.

...

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.

Well, you can if you need to. Which raises questions like, how

do you convert between the two and what's the event rate?

You can convert controll signals (the code you write yourself) to audio using either "step" or "impulse", both are Ugens you might want to look up. You can get audio-rate values to base conclusions/events/modulations/whatever on by polling myugen.last(). The event rate is whatever you make it; it equates directly to the amount of time you advance each loop itteration. However; to detect things like edges and zero crossings you'll need to advance time by just one sample each itteration and loops like that eat a lot of cpu. 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.

Fair, but our manual costs less money then that book (in fact it's free) and hence it has a volunteer maintainer who's currently bussy with more urgent stuff. To asist in that I started a page on the WIKI to list things that are unclear to people or outdated, missing or downright likely to cause nuclear melt-down or family dramas. If there's something identifiable that you find confusing or unclear then you are mroe then welcome to join in; anybody can join the WIKI and add pages.

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.

A book would be nice yes, but that's far off. I think the closest thing yet is Ge's accedemic papers that basically attempt to convince that running ChucK is a good idea at all. C does have books but C is quite old, proven to be usefull, not widely regarded as likely to explode nor is it -currently- a very experimental sort of thing. Perhaps most importantly; when you confess to using C people don't look at you attempting to determine wether you are mad. This is all quite unlike ChucK <grin>.

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.

You can. Adding a file that has a public class to the VM will instantly make that class available to other ChucK programs. In fact you could allways start Chuck using; chuck --loop my_class1.ck my_class2.ck my_class3.ck Perhaps through a batchfile, and all your classes would always be there for you to use.

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.

That's a thing for the future. Considdering the latency that the Windows drivers give I'm quite happy to have implemented realtime input quantisation... This is still good fun, I can now hammer buttons randomly and the output will still be in perfect sync.

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.

Go for it! 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 ...

Most likely you can controll it using "keyboard repeat rate", that's in your Windows keyboard settings.

...

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.

That's exactly what I was aiming at. Another thing I learned in a interface design class was that people can learn a lot, interface wise, but as soon as they panic this breaks down. The example given was aircraft design. That's a good example of a highly complicated interface that needs to stay usable under high stress.... Kas.