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

2 questions
by michael breitenbach 14 Dec '05

14 Dec '05

hi, 1. is it possible to create a event from a audiosignal (for example a pulse force a event)? 2. and is it possible to use a audiosignal as a float value in chuck code - like a snapshot function? sinosc a => float x => dac; // this doesn't work micha

2 1

chuck manual
by James Baker 12 Dec '05

12 Dec '05

hey chuckers, i just spent a bit of time looking through the wip manual pdf and ive got to say im impressed. this thing is far superior than most ive seen - commercial or free. its things like this that imho will make chuck stand out. keep up the good work, james ps. its almost christmas, wheres audicle + the toys ? ;)

1 0

Segmentation fault
by Ollie Glaskovik 12 Dec '05

12 Dec '05

Sometimes I get a segmentation fault when loading a new sample into a sample buffer that's already playing. Sometimes it doesn't seem to cause a problem. Is there anything I can do to prevent these crashes? Thanks, Ollie

2 1

ffmup chuck duet video + new power toys
by Ge Wang 06 Dec '05

06 Dec '05

Greetings, Perry and I rendered another chuck performance/disaster last night as part of FFMUp in Princeton. Perry played the VOMID (Voice-Oriented Melodica Interface Device) [1] and projected the sound through the amazing Noggin-phonics speaker head (also a PRC production), while I programmed on-the-fly: http://soundlab.cs.princeton.edu/listen/chuck@ffmup-2005.11.29.mov The breath pressure sensor, joystick, sliders, and linear FSR 1 on the VOMID controlled a live vocal model in chuck; the consonants (and belching) were sound clips, played by the keys and linear FSR 2 - all projected through metal head + mounted speakers of the Noggin-phonics! (The wild spatializing effect of this is unfortunately lost in the video.) Another notable aspect of the ordeal was the debut of two new chuck things, soon to be released. Both are authored by Spencer Salazar, a most righteous programmer and CS major here at Princeton. The ChucK Shell is a built-in command line interface *within* chuck, from which on-the-fly programming commands (and even live code) can be issued with great efficiency. The other is a prototypical native ChucK editor (called the miniAudicle, using Cocoa on OSX, Win32/MFC on Windows, and we-haven't-decided-what on linux). This will be released along with the Audicle, to add to our arsenal of chuck power toys. We will be hearing more about both the shell and the miniAudicle very soon (they are still in intense development)... So a big thanks to Spencer, and to Scott Smallwood for setting everything up for FFMUP. Best, Perry + Ge! --- Read more about the VOMID here: [1] http://hct.ece.ubc.ca/nime/2005/proc/nime2005_236.pdf

6 8

sndbuf.pos
by eduard 04 Dec '05

04 Dec '05

Hello all, I have a question for whoever is willing to answer it. Has one to always set sndbuf.pos at each iteration? My scenario: Let's say I want to control the starting position of my sndbuf with a midi keyboard while sndbuf is set to loop mode ( 1 => sndbuf.loop ). Midi is received in a sporked MidiReceive() function and my sndbuf.pos is set inside this same function and not in the main while- loop. Thus when I press a key the sndbuf.pos is changed for that loop, but when it gets to the end of it, it starts at sndbuf.pos(0) instead of the previously set one. So it seems that sndbuf doesn't keep track of the position that was set, and automatically starts from the beginning when the end of the audiofile is reached. Is this true? Thanks, Eduard

2 1

sndbuf.pos
by eduard 04 Dec '05

04 Dec '05

ok, I think i got the answer. Sorry, but when one gets obsessed by something he becomes blind. sndbuf.pos it's just the current position in the buffer and it is obviously changing all the time.

1 0

Re: [chuck-users] The ChucK Manual prerelease
by Felix Meinhold 02 Dec '05

02 Dec '05

Hi, > Do you have cvs access? You should be able to do an anonymous cvs checkout and > grab all of the code. If that doesn't work for you then I am more than happy to > host a tarred up version somewhere for people to check out. > > Here is how to do it: On Linux (or maybe on ArchLinux only) you have to tell cvs what remote shell to use for :ext: export CVS_RSH=ssh; cvs -d :ext:anon-chuck at cvs.cs.princeton.edu:/cvs checkout chuck_dev (export works with bash/zsh) felix

1 0

The Freesound Project
by Nelson Ferraz 01 Dec '05

01 Dec '05

Interesting project: The Freesound Project aims to create a huge collaborative database of audio snippets, samples, recordings, bleeps, ... released under the Creative Commons Sampling Plus License. The Freesound Project provides new and interesting ways of accessing these samples, allowing users to * browse the sounds in new ways using keywords, a "sounds-like" type of browsing and more * up and download sounds to and from the database, under the same creative commons license * interact with fellow sound-artists! We also aim to create an open database of sounds that can also be used for scientific research. Many audio research institutions have trouble finding correctly licensed audio to test their algorithms. Many have voiced this problem, but so far there hasn't been a solution. http://freesound.iua.upf.edu/

1 0

performance of chuck
by Atte André Jensen 30 Nov '05

30 Nov '05

Hi I've made a working version of the midi setup I've been rambling about. Now that I make som reak music with the setup I've made a few new observations. Most problematic is the fact that chuck often (well not often, but sometimes) click and pops, esp at noteons, but also other places. I guess I have to see if I can reduce the code run at noteon time, right? But besides that is there any general approaches for making chuck run more smoothly? Just as anoying is the fact that if I punish chuck with too many notes she breaks up the audio. That's just the way it is and I can live with that. But the problem is that after such an incident timing seems to be very sloppy. I could post some examples if someone care to look at them. I'm sure my code can be optimized quite a bit. But I guess the above is still valid since optimized code will behave similar if pressed hard enough. As a final remark at least the following code is totally un-elegant (I have a feeling Chorus is not the cheapest UGen around), but I can't figure out how to envelopes on a stereo signal (and Chorus is mono anyways, or?): sinosc s1 => ADSR env => pan2 pan; sinosc s2 => Chorus chor_l => ADSR env_l => pan.left; sinosc s3 => Chorus chor_r => ADSR env_r => pan.right; pan => dac NB: Still under linux/debian/unstable with realtime kernel from demudi. NB2: With csound I was able to enhance performance by running in a virtual terminal without X. But with chuck, that doesn't semm to make much difference. Neither does running as root. Neither does running with nice -19 and killing a few daemons.... -- peace, love & harmony Atte http://www.atte.dk

5 10

stereo suggestion
by Atte André Jensen 30 Nov '05

30 Nov '05

Hi I mentioned this already in the middle of something else, but recieved no reply, so I thought I'd start a new thread. It would make sense to have all UGens stereo aware. This might include supplying all with a .pan, .left and .right parameter, but at least it should be possibe to route a stereo signal through them and get a stereo signal out. Would that be expensive, both in execution time and in coding time for the developers? -- peace, love & harmony Atte http://www.atte.dk

2 1