April 2009 - chuck-users - lists.cs.princeton.edu

Colossal Error
by mike clemow 20 Apr '09

20 Apr '09

Yes! I finally made ChucK barf this up: mcchuck(23354,0x1825a00) malloc: *** Deallocation of a pointer not malloced: 0x603e7c; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug [chuck](VM): internal sanity check failed in shredule() [chuck](VM): (shred shreduled while shreduled) mcchuck(23354,0x1825a00) malloc: *** Deallocation of a pointer not malloced: 0x603e7c; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug [chuck](VM): internal sanity check failed in shredule() [chuck](VM): (shred shreduled while shreduled) mcchuck(23354,0x1825a00) malloc: *** Deallocation of a pointer not malloced: 0x603e7c; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug [chuck](VM): internal sanity check failed in shredule() [chuck](VM): (shred shreduled while shreduled) Killed I had to kill the process in the end, which was spinning in an infinite loop of some sort. I have to admit, the code I'm running ALWAYS crashes, however, often just with the regular Mac OS X 10.4 catch-all, "bus error". Full disclosure, this is a custom build of chuck with one minor modification: the Object.typeOf() stub is filled out with code from the Object.toString() method slightly modified to just return the string version of the class of the object so that I can determine the type of objects in code. But I never use that in the code I'm running right now. The bus error is totally repeatable in regular ChucK 1.2.1.2, but it's going to be a while before I get as spectacular a display as this. ;-) Of course, then I turn up the output of the VM to --verbose10, it won't crash properly, however, it does skip occasionally and tell me: [chuck]:(9:FINEST): (via rtaudio): OS-X audio output overrun detected! Perhaps increasing the buffer size on the audio system would help? I'll see if I can't get a trace of it crashing again. Cheers, Mike -- http://michaelclemow.com http://semiotech.org

1 0

UAnae / Vocoder question
by Peter Esveld 20 Apr '09

20 Apr '09

Hi ChucK List, While googling, I came across this really great shred that works as a vocoder: http://www.lullcec.org/chuck/fft/vocoder.ck<http://www.lullcec.org/chuck/fft/> The shred allows you to use a wav file as a "template" to vocode mic input. My question is this - can it be used with other shreds without vocoding all sound coming out of the Virtual Machine? Currently, any other shreds I add to the Virtual Machine have the wav file (vocoding) applied to them as well. I'm pretty new to ChucK, so please excuse the ignorance about these kinds of scoping issues. I've also attached the file in question (pretty much unmodified from the original). I'd like to use the vocoding effect only on sounds coming in from adc.left... I've emailed the author, and he's unsure what the problem is - he's going to investigate, but I'd really like some additional takes on the problem. Any thoughts or responses would be hugely appreciated! best, Peter -- Peter Esveld .......................................... 952.818.6488 peter.esveld(a)gmail.com ..........................................

3 5

Fixed so quickly.
by Andrew C. Smith 20 Apr '09

20 Apr '09

I didn't expect it to fix it that quickly, so sorry for the double-post. Here's what I did. This is my new eternal loop: while( true ) { // wait on midi event min => now; // get the midimsg while( min.recv( msg ) ) { // catch only noteon //if( msg.data1 != 144 ) // continue; // check velocity if( msg.data1 == 144 ) // THIS IS WHAT I CHANGED, from msg.data3 > 0 to data1 == 144. { // store midi note number msg.data2 => on.note; // store velocity msg.data3 => on.velocity; // signal the event on.signal(); // yield without advancing time to allow shred to run me.yield(); } else if( msg.data1 == 128 ) // ALSO THIS, from else to what it is now. This is to handle noteoffs which are all coming as [128 key 64] messages. I think I understand events now. { if( us[msg.data2] != null ) us[msg.data2].signal(); } } } Curious to know, has anyone else had problems with the polyphony examples? Although my keyboard seems to act in the expected way with Max/MSP (using midinote and poly~) ChucK will not see that. What's the deal exactly? -Andrew

1 0

Re: [chuck-users] The ChucK Show!
by Les Hall 18 Apr '09

18 Apr '09

Yeheheheah! The show rocked this week just like last week and Jan even got a recording! Next week: my Paranoid Schizophrenia album in it's entirety for the full show, and after that I'll once again shamelessly rip songs off of the ChucK wiki and etc etc etc... Please send your submissions to this email list, I'll play 'em! Take care, Les (Inventor)

2 1

Diatonic keyboard
by Hans Aberg 18 Apr '09

18 Apr '09

I was able to find one working combination by simply disconnecting the generators when the keys are released. ChucK does not seem to consume much resources at all. So I report it back here (I will do more work later). It is nice to play both melody lines and chords. The attached file contains descriptions. Hans

1 0

Re: [chuck-users] Keyboard Stuff
by Hans Aberg 18 Apr '09

18 Apr '09

On 18 Apr 2009, at 08:26, Kassen wrote: > I agree with you here but I feel that voice cycling is quite > different from GC. Of course they can be similar; a voice that's no > longer used might become garbage, depending on the structure used It was not intended as a far reaching analogy - only that one may end up programming side issues rather than the main task. >> If there was a simple way, if that now was needed, to just being >> able to add generators and the program could sort out which ones >> were needed for the sound output, would that not be great? > > Yes, and it does this; ChucK only calculates UGens that are > connected (directly or through other UGens) to the dac or to > blackhole. No other UGens take cpu (at least not for calculating > sound). The problem with not calculating ones that are silent (as I > think you are sugesting) is that I might do things like have a > sample player connected through a envelope to fade it in and out > while it plays. If we wouldn't calculate the sample player we'd have > no way of knowing where in the sample it should be playing when it > is faded back in again. Yes, it may be a difficulty issue and not always possible. In the case of the fader, it must able report back to the source that it is not needed. - So there might be needed something similar to lazy evaluation or ray back-tracing. Such things must then be supported by the programming language. > ... what you likely need is a series of parallel sound sources and a > way to link those to notes. I will probably just start off with a few generators which will be allocated if available. There is a problem with key roll over on a typing keyboard, but one can learn to avoid it. >> Each new key, which initiates a sound generator, adds in CPU power >> after being allowed to settle down and not producing sound anymore >> about as much as 3 times when as full program at startup time. So >> there is a quick buildup of from these idle generators. > Yes. One of the factors here, aside from the BeeThree's is that you > use two Echo's and a reverb for each voice. Because both of those > effects are linear and time-invariant it doesn't matter (for the > sound) whether we send a BeeThree through it's effects, then mix the > effects together or whether we mix the BeeThree's and send all of > them through the effect chain. Now; while this may not matter to the > sound the second option does save us rather a lot of UGens, and > especially reverbs take a lot of CPU. I might try to simplify that. The echo effects may not be necessary at this point, I just want some pitches. > > Such a resource consuming problem might be fixed if each sound > generator could turn itself to sleep. Say there is a cutoff-level, > or something. > > Yes. there are two ways of doing that. First of all you can > "unchuck" (or disconnect) a UGen and when you do it will no longer > consume CPU. Like this; > > SinOsc s; > > while(1) > { > if ( s.isConnectedTo(dac) ) s =< dac; > else s => dac; > second => now; > } Thanks. I was just about to look for this. > Another way of making a UGen stop consuming cpu is to make the shred > that contained it's defininition (which is also the namespace > containing it) leave the VM. like this; > > JCRev r => dac; > .5 => r.mix; > > repeat(20) > { > spork ~ play ( Std.rand2(1,5) * 200, Std.rand2f(.5,2)::second ); > .5::second => now; > } > 5::second => now; > > fun void play( float freq, dur length) > { > SinOsc s => Envelope e => r; > .5 => s.gain; > freq => s.freq; > .5::length => e.duration; > 1 => e.keyOn; > .5::length => now; > > 1 => e.keyOff; > .5::length => now; > } > > Note, that while both methods free the CPU again neither frees the > memory used by the UGen. THat is less of a problem, in view of virtual memory. > I think that in the case of the last example we can free the memory > as well by making the function read like; > > > fun void play( float freq, dur length) > { > SinOsc s => Envelope e => r; > .2 => s.gain; > freq => s.freq; > .5::length => e.duration; > 1 => e.keyOn; > .5::length => now; > > 1 => e.keyOff; > .5::length => now; > > null @=> s; > null @=> e; > } > > that's a bit hacky though. It's good to get an idea of it. I did look a bit at the dynamic allocation of arrays. > Hope that clarifies. Yes. Thank you. Hans

1 0

Keyboard Stuff
by Les Hall 17 Apr '09

17 Apr '09

Hans, Yes, you can do it simpler than that. I don't know for sure but I think the degeneration problem is because you are ChucKing up patches dynamically but never unChucKing them. So they build on top of one another and corrupt. Not sure but that's my guess. This may not be quite your answer, but i did implement a monome-like keyboard interface in my Digitar program. It does a crude attempt at Karplus-Strong string synthesis, which amazingly sounds like a real guitar. When you start the program it is silent, then when you press alphanumeric keys that puts logic table entries into the boolean sequencer that plays the guitar. Press F1 thru F4 to page the monome-like keyboard interface among the four vertical positions in the logic table, and press other function keys followed by the +/- keys to adjust stuff like distortion, reverb, etc. Oh, and watch the console monitor for the user interface. Enjoy! Les

5 16

Re: [chuck-users] Keyboard Stuff
by Hans Aberg 17 Apr '09

17 Apr '09

On 17 Apr 2009, at 20:19, Kassen wrote: >> Even the ASCII keys may differ from the US, like the German >> keyboard layout, which swaps "z" and "y". > > There was a debate about that on this list a while ago. I think the > conclusion was "It's a confusing mess but it can be worked with with > some effort and care". Maybe that's just what I concluded though :¬). It strikes me that Chuck may not be good for mixing key numbers with the translated "AsCII" numbers. Ir seems one has to make choice of what to use. When mixing, one may want to pick up the event first and looking at both the key and the (eventual) Unicode number. So when doing a Hid kb; ... kb.recv(msg) one would want a function msg.char() that returns an "int": say -1 if no character, or the Unicode code point (character number) otherwise. Hans

1 0

Polyphony
by Hans Aberg 17 Apr '09

17 Apr '09

Is there a better way to have parallel sound generators? - The key map in the attached file quickly corrupts on my computer: I want one for each key. (It is set in E31 with the key "J" set at A = 440 Hz, in the layout C# D# E# C D E F# G# A# B# Cb Db Eb F G A B Fb Gb Ab Bb C' And the organ sound generator is from hid/keyboard-organ.ck.) Hans

1 0

Re: [chuck-users] Using typing keyboard for playing
by Hans Aberg 16 Apr '09

16 Apr '09

On 16 Apr 2009, at 02:33, Kassen wrote: >> There are problems with using MIDI-patches as they may not be able >> to produce intermediate pitches - pitch bends en E12 may also >> change tone color. > > Yes, I see. Fortunately with ChucK you can implement pitch-bend (if > you'd like to use it) in any way you see fit. There is a MIDI Tuning Standard (MTS) which allows one to set frequencies, but it is not widely implemented. And even that ignores the problem of scale stretch. >> Actually, I only played piano accordion. I was led to the diagram >> when trying to find something better than the E12 buttons. > > Me too, and now, years after I quit, I still have a inclination to > want to put musical keyboards vertical on the rare occasions that I > play them :¬). There is the Korg nanoKey which resembles accordion piano keys somewhat, and the Roland virtual accordions, but they are a bit ore pricey. Otherwise, the key map was known (in a mirror reversed version) in the 19th century, by Helmholtz and Bosanquet. >>> I myself favour the exact opposite in keyboards; a longer key- >>> travel with a distinct "click" (like the IBM Model "M"). Odd, >>> maybe as I used to play the accordion and still have one stored. >> >> There are different styles, but the sensitive firm touch is good >> for full-grown accordions when playing rapid music (like Balkan >> music). >> >> When playing buttons, the hand must be m,ore curved, and one cannot >> use much force. So I think more sensitive keys would be better for >> that. > > Oh, yes, I wouldn't dream of using the style of keyboard I like for > typing on a accordion. Composers use MIDI keyboards for typing when entering the score (into programs like Finale and Sibelius). >>> For your purposes the best tip I could probably give is that the >>> "midi" section of the examples also touches on polyphony. I think >>> you will benefit from looking at those examples as you are clearly >>> after chords. >> >> Perhaps, if one can avoid that microtonal tone color problem. > > Without pitch-bend I'd still assume you would want your keyboard to > be polyphonic. I don't think those examples even go into pitch-bend > but I might be mistaken. I meant that those examples will show you > how to do voice-cycling which is a rather useful technique as it > will avoid "garbage" in ChucK. Yes, thank you, it will take me some time to get to those examples. On keyboards, I think even when playing a single line legato, there will be overlap of keys. Once (two decades ago) I had a MIDI synth with limited simultaneous notes, and with too few sound generators assigned, the audio would be truncated. Hans

1 0