- chuck-dev - lists.cs.princeton.edu

openGL + ChucK
by Jeremy Hunt 04 Feb '08

04 Feb '08

Hi all, I have heard of an openGL implementation planned for chuck, is someone out there actively working on one? Please let me know. My coding talents are meager but I would love to help. I could do tedious grunt coding that doesn't take skill :D Best, Jeremy

2 1

video playback/processing
by Jeremy Hunt 18 Jan '08

18 Jan '08

Hi All, I know OpenGL is planned but just wondering if there is any work being done on adding video processing to chuck? Best, jrmy

2 4

Bugs Report
by lucas samaruga 18 Jan '08

18 Jan '08

Hi at all I'm sending a zip file with contain a few .ck files and a readme.txt that contain bugs (not the .txt -laughters-). They have emerged on my chuck learning experience. Because I don`t speak to much english I send this telegram. The chuck verision is 1.2.1.1 Thanks and see you

1 0

Anti-aliased oscillators
by pibsid＠suomi24.fi 13 Jan '08

13 Jan '08

I recently posted anti-aliased versions of the basic oscillators in the chuck forums. They're based on integrating the oscillator's function over phase changes to get the average value over one sample. Here's an example of an anti-aliased saw wave taking the current phase and the difference to the next phase as arguments: fun float fun_aa_saw(float t,float delta_t) { t-Math.floor(t+0.5) => float t1; t+delta_t-Math.floor(t+delta_t+0.5) => float t2; return (t2*t2-t1*t1)/Std.fabs(delta_t); } They're quite heavy on the CPU because they need to ticked every sample in ChucK so it would be nice to imlement them on the source level. We do have the Blit versions of the oscillators but they only reproduce the sound of the osc they're band-limiting. Average-anti- alias keep the waveform more intact while still considerably reducing frequency leaking. How do I design oscillators on the source level of ChucK? Yours, Pyry Pakkanen

1 0

chuck and midi clock (again), ignoreTypes() method
by Julien Canet 17 Dec '07

17 Dec '07

Dear All, I am learning chuck and I've made some scripts for the monome 40h interface (if someone wants I can post them). I really need to sync my script with another software, using MIDI. I saw on the users mailing list ( https://lists.cs.princeton.edu/pipermail/chuck-users/2006-April/000503.html ) that midi sync wasn't possible. I didn't really understood why at first, because I thought we just have to make a midi input handler that waits for MIDI clock messages, just like the example in the message : 0 => int device; // number of the device to open (see: chuck --probe) MidiIn min; // the midi event MidiMsg msg; // the message for retrieving data if( !min.open( device ) ) me.exit(); // open the device spork ~ handleMIDI(); fun void handleMIDI() { while (1) { min => now; // wait on the event 'min' while( min.recv(msg) ) // get the message(s) { if (msg.data1 == 248) { // MIDI Clock // Do clocky stuff, count to 24, determine delta-now, whatever } } } } So I wrote a little loop waiting for midi clock message, similar to the script above. I never received midi clock messages... (I am sure they are sent using a MIDI monitor). I read on chuck forum that MIDI clock messages were not parsed. So I had a quick look into Chuck source code and try to found why. I said quick look because I do not understand the whole code to 100%, I've just tried to find more about these MIDI clock messages. I saw that in the midiInputCallback, the midi time code and tick messages (and some other midi messages) are ignored depending on some RtMidiInData flags : the ignoreFlags, initialized to true (ignoreFlags set to 7 in fact) in the constructor. If these flags are true, the size of the message is set to 0 and it is ignored. I saw that there is a method called RTMidiIn::ignoreTypes that can changes these flags. But my BIG question : how to access this ignoreTypes method in chuck language? I recompiled chuck with ignoreFlags initialized to 0. And now I received them... So what is the problem with the midi clock messages? Why disabling them? Can the end-user re enable them without recompiling? Thanks and congratulations for chuck, this is really wonderful, Best regards, Julien.

1 0

multi-channel in chuck
by Jeff Smith 14 Dec '07

14 Dec '07

I'm new to Chuck but am beginning to build out a toolset for future compositions. I'm a first year Phd student in computer music @ Stanford. I did my b.s. in computer science long ago... I'm attaching two code examples. The first is a sample for using chuck with 4-channel sound output. The second is a composition that uses this technique. The second example is less a composition, more a proof of concept. From it, I hope to create a fugue of engines (including a lawnmower, blowdryer, xbox360, hedge trimmer, and handmixer, and leafblower) . (If you require concrete sound files let me know). I find most composition by tape is arduous and suffers from too many dependencies among the various tools and iterations of output across those tools. As a contrast, I want to create sound-sculptures -- namely, a discrete entity (e.g. a single chuck program) that requires no pre or post processing. Changes to the entity affect the whole. Extensibility, however, becomes built into the structure. If you review the code, the extension to n-channel will seem reasonably straightforward. Jeff

1 0

Data Structures in ChucK
by samuel lenz banina 27 Nov '07

27 Nov '07

Dear ChucK Team, First of all, thank you for such a fun piece of software. It's getting hard to count the number of hours I've joyfully wiled away using ChucK. I'm a CS major at Notre Dame and I'm looking for ways to improve use of data structures in an open source project for a class. I've been digging through the ChucK and audicle codebases looking for things to improve, and amongst the many files I know I didn't catch everything. So my question is, as developers, are there particular uses of maps, lists, trees, hashes, etc. which you know to be sub-optimal? I've found a couple usages I may be able to tweak, but if I could focus my energy somewhere that could actually use it, all the better. (Who knows, if it's a good improvement maybe it'll make it back upstream?) Thanks in advance for any pointers you can send my way. Keep on ChucKing, Samuel Banina

1 0

ASIO miniAudicle
by Leuthold Dominik 21 Nov '07

21 Nov '07

hi list with the help from some kindly guys of the chuck forum i was able to compile a miniAudicle with ASIO support. i made a little tutorial in the forum about how i did it. you can look at that thread and also download the mini: http://electro-music.com/forum/viewtopic.php?t=21893 <http://electro-music.com/forum/viewtopic.php?t=21893&sid=8003eb3049f7615779 9c76ff9fc174b3> &sid=8003eb3049f76157799c76ff9fc174b3 however, i noticed some strange behaviours with this version and hope that somebody from this list has some ideas or hints what could cause it. - the audio channel assignation is somehow messed. i get always only on one channel sound (which isn't the idea of asio at all ;) i found out, that i only get sound on the highest channel of the maximum defined channels. for example: with 4 enabled output channels -> only dac.chan(3) will work; with 8 enabled output channels -> only dac.chan(7) works. i have the same problem with an own compiled asio chuck version, so it is not a mini specific problem. the real strange thing is, that the asio version of phillipe lamarc is working fine on my machine, so it must have something to do with my compilation process :-( - since asio drivers will only work with a single application, i noticed that the mini remains alive after closing the application. i had a little "deja vue" and found this one in the release notes for version 0.1.3.4: - (fixed)(Win32) miniAudicle process no longer persists after exit the actual official version of the mini is closing correctly, but probably it has some dependencies to this fixed bug? thanks for your help /moudi

1 0

Envelope fixing
by Kassen 30 Sep '07

30 Sep '07

Dear devs, After a bug in Envelope was found I tried my hand at fixing it which brought yet more issues to the surface. I also tried to fix those but I'm not sure what this might now break so I'm out of my depth. Details and code are here; http://electro-music.com/forum/viewtopic.php?p=142167#142167 Documentation of the various things that went wrong with the official version are above that post. A copy of what I arrived at follows below, I hope this is of some use, if my code isn't I can at least say we now have a clearer image of exactly what the issue is and I had some fun. Yours, Kas. ================================================================== /***************************************************/ /*! \class Envelope \brief STK envelope base class. This class implements a simple envelope generator which is capable of ramping to a target value by a specified \e rate. It also responds to simple \e keyOn and \e keyOff messages, ramping to 1.0 on keyOn and to 0.0 on keyOff. by Perry R. Cook and Gary P. Scavone, 1995 - 2002. ---------------- This is a experimental "fixed" version by Kassen who doesn't speak C++. Don't use this for anything important untill the official devs have had a look at it, Don't say I didn't warn you. this is a modification on ugen_stk.cpp for chuck 1.2.1.0, which is covered by the GPL (and so so is this). */ /***************************************************/ #include <stdio.h> Envelope :: Envelope(void) : Stk() { target = (MY_FLOAT) 0.0; value = (MY_FLOAT) 0.0; rate = (MY_FLOAT) 0.001; m_target = 1.0; m_time = rate * Stk::sampleRate(); state = 0; } Envelope :: ~Envelope(void) { } void Envelope :: keyOn(void) { target = (MY_FLOAT) m_target; if (value != target) state = 1; setTime( m_time ); } void Envelope :: keyOff(void) { target = (MY_FLOAT) 0.0; if (value != target) state = 1; setTime( m_time ); } void Envelope :: setRate(MY_FLOAT aRate) { if (aRate < 0.0) { printf("[chuck](via Envelope): negative rates not allowed ... correcting!\n"); rate = -aRate; } else rate = aRate; m_time = (target - value) / (rate * Stk::sampleRate()); if( m_time < 0.0 ) m_time = -m_time; } void Envelope :: setTime(MY_FLOAT aTime) { if (aTime < 0.0) { printf("[chuck](via Envelope): negative times not allowed ... correcting!\n"); rate = (target -value) / (-aTime * Stk::sampleRate()); } else if( aTime == 0.0 ) rate = FLT_MAX; else rate = (target - value) / (aTime * Stk::sampleRate()); if (rate < 0.0 ) rate = -rate; m_time = aTime; if( m_time < 0.0 ) m_time = -m_time; } void Envelope :: setTarget(MY_FLOAT aTarget) { target = m_target = aTarget; if (value != target) state = 1; // set time setTime( m_time ); } void Envelope :: setValue(MY_FLOAT aValue) { state = 0; target = aValue; value = aValue; } int Envelope :: getState(void) const { return state; } MY_FLOAT Envelope :: tick(void) { if (state) { if (target > value) { value += rate; if (value >= target) { value = target; state = 0; } } else { value -= rate; if (value <= target) { value = target; state = 0; } } } return value; } MY_FLOAT *Envelope :: tick(MY_FLOAT *vec, unsigned int vectorSize) { for (unsigned int i=0; i<vectorSize; i++) vec[i] = tick(); return vec; } MY_FLOAT Envelope :: lastOut(void) const { return value; }

1 0

TriOsc.width()
by Dean McNamee 26 Sep '07

26 Sep '07

>From looking at the code, since there was already an unused osc_cget_width I figured this was just missed, or is there any reason why you wouldn't want a width getter? Didn't test the patch at all but I figure it should work. Thanks very much for ChucK

1 0