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.

Hi, Velli-Pekka! Wonderfully interesting points!

[UI for synth panels] 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 figure out how to run scripts in it, <embarrassed emoticon>.

Ah, yes. I'm on Win and Linux as well but my eyes still work (though they are going down....) so I saw the screenshot of the Mac version. This screenshot shows sliders and leds and so on and the idea is of course that this will be extended. Making those screen-readable now seems like a good idea, especially since I imagine that in the long run more visually impaired people will try programing for their electronic music needs, the idea seems very natural. 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.

Right, yes. I think that here Spencer's point of view is close to my own. As I understood it Spencer wants to integrate such things with ChucK itself, not make it into a exception. I think that this would make it more versatile and powerful in the long run. For novice users it might be harder to use at first but that trade-off might be worth it. I think we can assume that anyone who is using it will be already familiar with implementing functionality using ChucK. The same goes for MIDI learn. You are quite right that MIDI learn needs a way to indicate what parameter is meant and right now -without a graphical interface- that would be a rather primitive affair. As soon as the graphics get here it would need a night of clever thinking but be very possible. This might be a good topic for a future example to be distributed with the Mini. 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.

Ah! I think that I myself run one of the Windows settings meant for disabled people; I use one of the high-contrast B&W ones because I find them easier on the eye and more clear. [accessibility]

Basically yes. My rather technical definition is that they are apps that 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.

Got it. This is the sort of thing why we need alt tags for images and Flash is of dubious value and so on. 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 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.

Absolutely. Now that I think of it it's quite remarkable that nobody -that I know of- pointed out the interesting benefits that livecoding and generally using programing as a musical instrument might have for the visually impaired.

...

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.

Oh, yes, and the need for split-second decisions while in chaotic environments like when performing in a nightclub. [HID API]

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

Personally I like this. Right now I work with ChucK and the Nord Modular and I find it very convenient to be able to play ChucK with the keyboard while the Nord editor is in focus and addressed by the mouse. If this isn't what you want you might want to try the non-hid keyboard interface; that one doesn't do this and demands focus. You would lose key up and key down messages though. 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.

I have some good news for you. As I mentioned; my eyes are fine for normal computer usage but I got tired of staring at the screen all the time in a performance context so I'm developing my own instrument (a house style sequencer) which is build around two HID gaming devices and is playable without using the screen at all. I still use screen prints to know what BPM I'm currently at and how much shuffle I'm using but only to help me make "presets". This is very feasible and I'd like to encourage you to try to do the same. A good pianist can play blindfolded so why not a techno producer? <provocative grin>. One thing that I've become very interested in is interface sonification for musical programs. I'm in the very early stages of testing that idea. My aim here is to stylise the interface sonification in such a way that it blends with the music, using some quantisation where it may be necessary. You might want to experiment in that direction as well. As Asio gets here this will feel more natural; realtime interface sonification depends heavily on low latency if you want to make it pleasing. I found that I tend to input commands rhythmically after listening to a beat for a while regardless of whether those commands have anything to do with the beat directly. Yours, Kas.

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. V, S, K = Veli-Pekka, Spencer, Kas [UI for synth panels] [mini-audicle] VV: I've yet to figure out how to run scripts in it, <embarrassed emoticon>. S: 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, V: Yes, that works, thanks. WHIch reminds me of a problem I found with the organ, more about it in the HID section. The step I failed to do here was to start the machine, I thought one could add a shread to it which would implicitly start it, or something like that. I actually tried Audicle before the manual so that explains things, too. S: you can also use the buttons at the top of the document window to add, remove, and replace shreds. V: Ah now that you mentioned them, I used virtual focus and found it. Here the problem is that they are toolbar buttons and in WIndows toolbars are not in the tab order. From an accessibility point of view, buttons close to the start virtual machine button in which you can tab or shift+tab to would be better. But it is good enough to also mirror the choices in the menus so there's at least one accessible, and discoverable route. K: screenshot of the Mac version. This screenshot shows sliders and leds and so on and the idea is of course that this will be extended. 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. K: especially since I imagine that in the long run more visually impaired people will try programing for their electronic music needs 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. VV: was thinking the panel objects could maybe export their serialized state. That info could be then stored in a file directly. K: As I understood it Spencer wants to integrate such things with ChucK itself, not make it into a exception. I think that this would make it more versatile V: Most definitely. If chucK had serialization across the board, you could also store modules efficiently in files and load them directly. Maybe, you could even send objects like Synths over the network. K: For novice users it might be harder to use at first but that trade-off might be worth it V: Yeah, although I like how much ChucK ressembles C-like langs and Java in particular. It made it real easy to learn. I wish the manual would have a quick conversion guide, too. Regarding serialization it need not be that hard. Many languages have one function to turn an object into binary and another to get it back. In scripting langs that's generating a string representation of the data structure and evaluating it on the fly, in simple cases. K: quite right that MIDI learn needs a way to indicate what parameter is meant and right now -without a graphical interface- that would be a rather primitive affair. V: Yes, but could be done. Most old games would have you input controls in exactly the same order every time with no undo or step back facility. That could work for simple MIDI instruments, though is of course, very clumsy. [accessibility] VV: didn't mean the GUI would be customizable in the app <snip> it would use the colors and fonts you had picked for your OS. K: think that I myself run one of the Windows settings meant for disabled people; I use one of the high-contrast B&W ones because I find them easier on the eye and more clear. V: Well, here we go again. ANd one advantage of truetype fonts compared to bitmaps burned in the synth panel is that the text size is changible for highRes or low-vision users, and localizable, too. It's a common observation that sometimes accessibility can improve usability, too, especially for keyboard powr-users. At other times, the two are in conflict, e.g. whether to skip over grayed out menu entries from the keyboard. [screen readers] V: apps that programmatically reduce the graphical user interface to text rendered as speech and or Braille. <snip> following focus changes, heuristically guessing which pieces of text are labels and augmenting the keyboard interface <snip> K: Got it. This is the sort of thing why we need alt tags for images and Flash is of dubious value and so on. V: Yes, although Flash could be made accessible, only people lack the interest and or knowledge. It's sad people think of the Web when they think accessibility, where as it is desktop apps your average Joe or Jane is using most of the time. Often their accessibility is much worse. Nough said. [uses for ChucK] K: it's quite remarkable that nobody -that I know of- pointed out the interesting benefits that livecoding and generally using programming as a musical instrument might have for the visually impaired. 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. 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'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. Similarly in computer science, as I have to view graphs one node at a time magnified, it is much easier to render the stuff on paper (laptop) or in my head as matrices, despite being much more a programmer than a mathematician of any kind. Also in Reaktor I have to spend time arranging modules on screen, which has absollutely nothing to do with how the synth operates or even looks to the user. Programming also gives you dynamic control for virtually everything. SAY I want to build an n to 1 audio switch, no problem, as the number of mixers instanciated can be parameterized. I have never used such a tac but howabout a synth which directly alters the patching and set of modules in it based on previous input and its current state, a complex Mealey state machine if you will. K: One thing that I've become very interested in is interface sonification for musical programs. 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. K: so I'm developing my own instrument (a house style sequencer) which is build around two HID gaming devices and is playable without using the screen at all. 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. K: found that I tend to input commands rhythmically after listening to a beat for a while regardless of whether those commands have anything to do with the beat directly. 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. [HID API and MIDI] VV: 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 the focus. I find that counter-intuittive and a potential problem if you multi-task several keyboard instruments <snip> K: Personally I like this. Right now I work with ChucK and the Nord Modular and I find it very convenient to be able to play ChucK with the keyboard V: I see, after choosing file/send message in the menu, I realized it all depends on the context. Most certainly, if you need to work with several music apps at the same time, that's handy. But suppose, if that's possible[?], I'd like to test my keyboard instrument, write some more code for it, and then reload the instrument without closing the chucK VM. In that case I wouldn't want to hear blips and bleeps while I'm coding. But one could remove the shread before coding, admitted. S: This is actually a feature, not a bug. The idea is to abstract the keyboard as just some device with buttons, <snip> it simply uses DirectInput. V: Ah I see, and agree that in this case, as there's an alternative API, the choice is quite sound actually. Of course it would be better to have a uniform API and a boolean flag to decide how to handle the focus. DirectINput is good, I do know those multi axes and button gamepads are well exposed via it. V: A funny thing about the organ. I've tried playing very fast in WIndows and it seems to me As though fast input is auto-quantized to some pretty coarse note value. I suppose this is a limitation of the keybord scanning, right? VV: 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. S: ChucK probably won't be able to read the pressure of your touchpad at this point. V: No prob, I really didn't expect it to. I've only looked into this minimally and it seems as though I'll need to download an SDK to begin with, to even use the pressure in my apps. It is no wonder the WIndows mouse API doesn't support a third axis. Here's an odd idea, using pressure to navigate window z-order i.e. switch between the children in a top-level window like an MDI app. [MIDI] V: Lastly, some feedback about MIDI: I mentioned MIDI processing as one potential use and find the current API a bit raw. It would be great if I could transparently handle either off_line MIDI data in a file or stuff that's coming in on the wire in real time. Further more, if it is off-line, would be very cool if the data could be idealized a little: note on/off pairs to note events with length, a bunch of controller messages to 14-bit NRPN and RPN messages and full sysex messages whose checksum would be auto-calculated basedd on the manufacturer ID, you get the picture. I think the current API is about as raw as in VSt which means getting the job done but reinventing wheeels in the process. Ideally, I'd like to work at the musician level without having to know about running status, handle channels by masking off nibbles in binary data and recalling or defining constants for the various event types. A Java-like API with dedicated event classes for each one would be great. Even a more primitive presentation as in MIDI Perl using arrays would be quite all right. -- 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 3/7/07, garton@columbia.edu wrote:

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.

I'm not sure I understand how this would be different from OSC or MIDI. It sounds to me like you could use OSC and get that IXIsoftware Python-OSC-graphical_thingy and have a open general purpose interface of your own to controll ChucK, Max and a wireless robot-toaster in exactly the way that you propose but I might (likely?) be missing something? Kas.

On 3/7/07, garton@columbia.edu wrote:

It's kind of my whole point, in that it is a lot different (at least for me).

I see now, didn't quite get all of this from your original mail. 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? That would be quite a thing! Kas.

On 3/7/07, garton@columbia.edu wrote:

and just compile-in the chuck lib. Within whatever app your are developing. No messing with net setup, etc.

Now I get it. And this whole thing could then be made to be a part of our own program and people would make a ChucKvst and firechuck (firefox plugin) and it would get embedded in freeware computer games (shmuck!) and we would all be very happy?

Kassen wrote:

Now I get it. And this whole thing could then be made to be a part of our own program and people would make a ChucKvst and firechuck (firefox plugin) and it would get embedded in freeware computer games (shmuck!) and we would all be very happy?

One thing for the authors to consider is if things start moving in this direction if they'd prefer to keep the GPL license or move to something like the LGPL which permits a couple of the examples above. At the moment doing a VST adapter or using ChucK in non-OSS freeware are not permitted by the license. Honestly, this is probably also problematic for chuck~. As for integration in general, yes, it is something that's important not just from an application developer's perspective, but from a musicians. I'm currently using a mix of Live, ChucK and VST plugins over a series of virtual audio and midi cables, but that makes restoring my environment for a given piece / performance rather complicated. 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. -Scott

and the same for maxpatches btw Op 8-mrt-07, om 12:34 heeft isjtar het volgende geschreven:

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 _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

But the interpreter point is irrelevant since the externals aren't written in Max. yes, you're right, only thought about that afterwards.

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

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?

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

I'm fairly certain this is the case. Others projects have encountered this problem. Because of similar licensing issues, VST support in Audacity must be packaged separately and under a different license. See: http://audacityteam.org/vst/ martin robinson

On Mar 7, 2007, at 8:18 AM, Veli-Pekka Tätilä wrote:

V: A funny thing about the organ. I've tried playing very fast in WIndows and it seems to me As though fast input is auto-quantized to some pretty coarse note value. I suppose this is a limitation of the keybord scanning, right?

The quantization in that example is actually enforced by that specific ChucK program. If you check out the code, you might notice an 80::ms => now; that is executed right after each key press. Removing that line will remove the quantization--then it should be able to keep up with faster input, unquantized.

[MIDI] V: Lastly, some feedback about MIDI: I mentioned MIDI processing as one potential use and find the current API a bit raw. It would be great if I could transparently handle either off_line MIDI data in a file or stuff that's coming in on the wire in real time. Further more, if it is off-line, would be very cool if the data could be idealized a little: note on/off pairs to note events with length, a bunch of controller messages to 14-bit NRPN and RPN messages and full sysex messages whose checksum would be auto-calculated basedd on the manufacturer ID, you get the picture. I think the current API is about as raw as in VSt which means getting the job done but reinventing wheeels in the process. Ideally, I'd like to work at the musician level without having to know about running status, handle channels by masking off nibbles in binary data and recalling or defining constants for the various event types. A Java-like API with dedicated event classes for each one would be great. Even a more primitive presentation as in MIDI Perl using arrays would be quite all right.

Yes, some expansion/abstraction of ChucK's MIDI implementation has been discussed before, and would be pretty beneficial. spencer

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

...

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 :-) I see, and most apps let you also move the mouse or send out keybord messages from gamepads, if all else fails. At .least the Gravis software does. ANother point is that some sighted folks don't like the mouse either. I do know people who positively hate drag and drop. Usability books also consider Uis that require right clicks, dragging or chord clicking as

Kassen wrote: [accessibility of the knobby panel UI] potentially unusable for new mouse users. [uses]

like you want it to work. It takes MIDI, HID and OSC so the sky is the limit. 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. I've been coding the last five years recreationally and so have had pretty much a free choice in terms of langs, apart from uni projects. SO I've grown to like the high-levle stuff, namely Perl and Java. So C plus plus is not my thing at all, if I can avoid having to use it, though Unix and C are a bit of an exception. THat's why I'm glad ChucK is what it is.

...

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 <snip> been with the Nord Modular since the beginning <snip> 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. That's right. Although you don't have parens in arithmetic expressions in modulars, as the signal flow determines precedence. Which reminds me how do ChucK and Nord Modular handle divide by zero? Most langs I know throw some sort of exception or call a signal handler. However, obviously the event divide module in Reaktor cannot simply stop processing at any point, especially in a live situation. I think IEEE floats have the types not a number and infinity so maybe dividing by 0 should give infinity, at least intuitively. Does ChucK support these special values?

In Tassman I have at times run out of space on the screen in complicated patches. At that point it is time to modularize. Kind of like the old programming rule of having a method or function limit of about an A4. IF it's longer than that, that's a bad smell. Of course, there are exceptional situations e.g. where avoiding the overhead of a function call is a major performance advantage.

Yes, most obvious is things like Windows making a click sound when you click your mouse. Totally pointless, at least to most people. But I've noticed after assigning different beeps for questions, warnings and notifications, that it is far quicker for me to detect what event it is based on a sound. i also tried samples of the screen reader saying the type very fast but processing that took a lot more mental CPu time. So I guess auditory icons might have their

[seqs] Firstly about auditive interfaces. place after all.

if the selected step comes up in the loop a click is heard in the main mix. This is a big help in programming beats while not having any visual feedback Sure, sounds interesting. Which reminds me, I've used the 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 also have an Alesis SR16 and in that counting steps manually, going in and out of the step edit mode to play is about as clumsy and frustrating as it gets. All context is dependent on being able to retain a consistant mental model of where you're going. Correcting a single live-input note timing in a pattern using such a system is wel, awful. One thing I'd like is the ability to shift individual steps left or right one or more steps, while having a loop close around that point in the pattern. WHen I do use a step seq, which is not often, I tend to input half of the things quantized live, do som editing and add the rest using the seq. In that context I often need to wait for 16-bars to move a single note around only to find out that it needs to be shifted one or more steps still to arrive at the desired rhythm. You asked about ideas. I like the fact that you can select a step for editing and if you hit a key at a time where there's no step, the next one will be selected. HAndy in deed. Although it's not very accessible, I like the controls in Fruity very much, too. Rotating the pattern left or right is nice and there's a fill function which could be described as function fillNth(int startPos, int n) in ChucK. That's certainly cool and a real time saver even though I'm going to remove some of the notes it adds and add others, 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? ChucK could do the timing in this. 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 interface for reading and writing the SId registers. In such use, having ChucK supply the timing could be a great benefit. If DLls are out what options do I have for inter-process communication within ChucK? My last idea concerns the ability to enter notes from the keyboard. ONe of the things I hfind hard in step seqs, be it hardware, Fruity or something else is knowing which step is which as I cannot see them all in sufficient detail. That means I'll have to count, say to add a hit every 5th note or something. And then it occurred to me. The function keys in a desktop PC 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

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. I'm out of the loop as far as new games go, so I'll use Wikipedia to find out more. 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

[future]

...

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. Oh yes, and a polymorphic Santa, depending on locale, <grin>. better play nice here so we might actually get some presents in a future release of Chuckmas.

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

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/

all

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.

i'm working on windows and have a good soundcard with ASIO drivers. (an rme hammerfall multiface). it's pretty frustrating for me to have such a card and can't work with it on chuck. (i even can't use the card itself because it has only mme, gsif and asio drivers...) if i can help anything to get asio into chuck, i'm really willing to do what i can. (write code, debuging, testing,... whatever you want) just let me know:-) regards /moudi -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out