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

safe delay
by Timothy Leonido 21 Apr '11

21 Apr '11

I am often getting a console message reading "DelayL: setDelay(-) too big!" I change the parameters in my patch but the warning persists. Any advice here? Thank you, Tim

2 1

SndBuf allocating 2x memory?
by Josh Adams 18 Apr '11

18 Apr '11

Hey everybody, After noticing my test SndBuf programs were eating more memory than I expected I started looking around on the list and wiki but couldn't find any relevant discussions. Here's how it goes: airj:~ josh$ chuck --version chuck version: 1.2.1.3 (dracula) exe target: mac os x : universal binary http://chuck.cs.princeton.edu/ airj:~ josh$ cat tmp/buf.ck SndBuf b; "tmp/bigfile.wav" => b.read; while (1::second => now); airj:~ josh$ du -sk tmp/bigfile.wav 769308 tmp/bigfile.wav airj:~ josh$ chuck --loop & [1] 20706 airj:~ josh$ ps -orss= 20706 4484 airj:~ josh$ chuck + tmp/buf.ck airj:~ josh$ [chuck](VM): sporking incoming shred: 1 (buf.ck)... airj:~ josh$ ps -orss= 20706 1531692 airj:~ josh$ Looks like ChucK/SndBuf's resident size is growing a little under 2x the size of the file I'm trying to buffer. Any ideas? Cheers, -josh

2 1

SndBuf resource usage
by Josh Adams 18 Apr '11

18 Apr '11

Hi there, I found a thread or two in the past that talked a little about this. I'm hoping that in the time since those discussions there've been some internal improvements to ChucK that might help me have a bunch of samples ready to fire concurrently without eating my box alive. Here's how I repro the issue (running on a late-model 2.13GHz MacBook Air): SndBuf buf[512]; // gets more responsive as I reduce to <384 or so fun void connect(SndBuf b) { b => dac; } for (0 => int i; i < buf.cap(); i++) { spork ~ connect(buf[i]); } while (1::second => now) <<< now >>>; If there's nothing I can do about SndBuf's wasteful behavior is there a better/more ChucKian-approved way to prepare a bunch of independent audio buffers (hopefully >1024) for arbitrarily-timed concurrent playback? Really hoping that the answer isn't that I need more cpu cycles on that core and/or that I'll need to distribute ChucK and set up some kind of sync mechanism :-/. I have very similar performance results with WvIn btw. Thanks a bunch! -josh

2 3

record and play multiple LiSa objects on multiple channels
by Harald Gutsche 11 Apr '11

11 Apr '11

Hi chuckers, Kassen: >Fortunately that's not correct. You can use quite a few, if you like; >LiSa a => dac; >LiSa b => dac; >//etc > >If this gave you trouble there is likely something else that went wrong. If you send a (minimal) example that demonstrates the trouble you had we can look at it and try to help. ok, I tried again to do the following (as a beginning): - record stereo sound - play it back in loops - save it in parallel ---------------------------------------- I tried many variations and until now didn't find a way to do this all together. Please use a fast panning stereo sound for all examples (e.g. one panning cycle in 1 second). I could simulate this in chuck, but then this would make everything less clear. Let's start with a first problem. LiSa as you said above can be instantiated multiple times, you are right, this works (and there are examples for that). The chuck crashes I mentioned in a former mail can be reduced to the following code: LiSa looper; // this works: adc => looper => dac; adc.chan(0) => looper.chan(0) => dac.chan(0); adc.chan(1) => looper.chan(1) => dac.chan(1); when running on chuck 1.2.0.8 (which was my first contact with chuck). Now I compiled 1.2.1.4-dev-2 (from the posted svn repo), which doesn't crash, "fine" you say. ---------------------------------------- So next thing coming to mind is: 2000::ms => dur record_time; //1 => int nchannels; 2 => int nchannels; LiSa looper; record_time => looper.duration; for(0 => int c; c < nchannels; c++) { adc.chan(c) => looper.chan(c) => dac.chan(c); } adc => dac; <<<"record", "">>>; 1 => looper.record; record_time => now; 0 => looper.record; adc =< dac; <<<"play", "">>>; looper.play(1); looper.loop(1); //for(0 => int c; c < nchannels; c++) { looper.chan(c) => dac.chan(c); } // go while( true ){ 1000::ms => now; } this seems to record only one channel which is played on both dac channels. ---------------------------------------- Ok, lets try another one, multiple LiSa objects connected to the adc/dac channels: 20::ms => dur crossfade; 2000::ms => dur record_time; fun void loop_sampler(int c) { LiSa looper; adc.chan(c) => looper => dac.chan(c); adc.chan(c) => dac.chan(c); record_time => looper.duration; <<<"record", c>>>; 1 => looper.record; record_time => now; 0 => looper.record; adc.chan(c) =< dac.chan(c); <<<"play", c>>>; looper.play(1); looper.loop(1); looper => dac.chan(c); 2 * record_time => now; } spork ~ loop_sampler(0); spork ~ loop_sampler(1); // go while( true ){ 1000::ms => now; } surprisingly, this doesn't play back anything in chuck 1.2.1.4-dev-2. I checked the general logic by simply replacing all occurencies of ".chan(c)" with nothing in the editor, which works, but is mono. But in chuck 1.2.0.8 it works unchanged!

5 13

Re: [chuck-users] wiimote hacks? GameTrak by Mad Catz is pretty cool...
by Robert Poor 10 Apr '11

10 Apr '11

[David: I'm adding chuck-users to the To: list -- hope you don't mind] On Sun, Apr 10, 2011 at 16:55, David Loberg Code <d.loberg.code(a)wmich.edu>wrote: > Any further advice on gametrak hacks? I found this DIY. > http://x37v.com/x37v/writing/mad-catz-gametrak-mod-for-maxmsp/ > Does it have to be a specific version of the gametrak? (i.e., gametrak > for x-box, gametrak for pc, etc.) > thanks, > david > I think that mod will work with "nearly any" GameTrak you can get your hands on, but I won't promise it. All I know is that I bought a Game Trak for $10 on Amazon, made the mod, and it worked on the first try. FWIW, the source code I just pushed to github has a bunch of GameTrak specific code, including a "raw MIDI to event" driver, a sensible filter (so your code doesn't get flooded with spurious updates), and a "pluck detector" (you can pluck on the monofilament to generate an event). Relevant files are "game_trak_*" in https://github.com/rdpoor/chuck_performance_setup/tree/master/lib - Rob

1 0

chuck_rational and chuck_performance_setup on github
by Robert Poor 10 Apr '11

10 Apr '11

ChucKers: By popular request, I've just created two ChucK specific "git repositories" that you can view, download and (if you are versed with git) create branches and update. One is a rational number package, that efficiently converts between floating point numbers and rational approximations (in the form of a/b, where a and b are integers). The other is the extensive setup I have used for live performance. One of the funner bits are: * lib/semaphore.ck, which can wait for an event or for a time, whichever comes first. * a comprehensive dispatch/observer message passing mechanism for distributing events. To get there: * https://github.com/rdpoor/chuck_rational * https://github.com/rdpoor/chuck_performance_setup Share and enjoy (code and comments, etc) - Rob

2 2

Re: [chuck-users] chuck-users Digest, Vol 69, Issue 10
by Timothy Leonido 09 Apr '11

09 Apr '11

Kas, that's exactly what i was looking for! Rob: I would be curious to look at that code if you don't mind dusting it off. Thanks! 2011/4/8 <chuck-users-request(a)lists.cs.princeton.edu> > Send chuck-users mailing list submissions to > chuck-users(a)lists.cs.princeton.edu > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > or, via email, send a message with subject or body 'help' to > chuck-users-request(a)lists.cs.princeton.edu > > You can reach the person managing the list at > chuck-users-owner(a)lists.cs.princeton.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of chuck-users digest..." > > Today's Topics: > > 1. controlling individual chuck patches (Timothy Leonido) > 2. Re: controlling individual chuck patches (Robert Poor) > 3. Re: Hello and the state of ChucK question (Mark Cerqueira) > 4. Re: controlling individual chuck patches (Tomtom) > 5. Re: Hello and the state of ChucK question (Harald Gutsche) > 6. Re: controlling individual chuck patches (Kassen) > > > ---------- Weitergeleitete Nachricht ---------- > From: Timothy Leonido <timothy.leonido(a)gmail.com> > To: chuck-users(a)lists.cs.princeton.edu > Date: Thu, 7 Apr 2011 19:50:32 -0400 > Subject: [chuck-users] controlling individual chuck patches > hello, > > could anyone offer advice on controlling individual chuck patches with an > external device? currently my mode of operation is to add several shreds > and control their parameters with maudi sliders (buf.rate, reverb, delay, > gain), but i'd prefer to use an external controller. > > i have an 8 channel alesis mixer with usb-- could this help to answer my > question? please let me know if you have any controllers in mind, and also > which section of the manual is best to read for making these connections. > > thank you! > > tim > > > ---------- Weitergeleitete Nachricht ---------- > From: Robert Poor <rdpoor(a)gmail.com> > To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> > Date: Thu, 7 Apr 2011 18:23:48 -0700 > Subject: Re: [chuck-users] controlling individual chuck patches > Hi Tim: > > 2011/4/7 Timothy Leonido <timothy.leonido(a)gmail.com> > >> could anyone offer advice on controlling individual chuck patches with an >> external device? > > > For my performance setup, I created a ChucK patch controller class -- it > received all incoming MIDI events and forwarded them to the current patch. > Not surprisingly, it intercepted patch control events, and did a > Machine.add() to launch a patch and make it current. It worked reliably for > me. > > Is that what you were looking for? > > If you want more details, let me know -- I can dig up the code from the > archives. > > - Rob > > > > ---------- Weitergeleitete Nachricht ---------- > From: Mark Cerqueira <mark.cerqueira(a)gmail.com> > To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> > Date: Thu, 7 Apr 2011 19:15:50 -0700 > Subject: Re: [chuck-users] Hello and the state of ChucK question > I've never used Savannah, but from what I have used: +9001 git / github if > you want to foster a "social coding" environment for the project in > question... > > mc > > On Apr 7, 2011, at 1:32 AM, Kassen wrote: > > > Tom; > > Savannah accounts are project based and need approval. > > > I think the projects need approval and that we fall squarely in the > category. > > > As was said earlier, I also think Github's fork feature is great - people > can fork off from the main ChucK branch, tinker around, and if they do > something cool, they can request that it be merged back in. > > I think that's all the control that's needed. People shouldn't need > permission to mess around with ChucK or even need permission to request > something be merged back into the master branch (this is assuming people > don't go crazy and swamp Spencer with pull requests). If we make people > bend-over backwards to contribute to a project, I can imagine they'd be less > likely to contribute? > > > >> On github, anyone can >> create an account, fork the chuck repository and publish his work in plain >> sight. >> > > That's exactly what I'm doing; > http://git.savannah.gnu.org/cgit/fluxus.git/log/?h=redacted > I forked the Fluxus audio synth called Fluxa and added a lot of stuff to > it. > > >> >> I see that as a strong advantage as the community can experiment, leaving >> to >> the main branch maintainers the possibility to merge interesting >> propositions >> in a few simple commands. >> >> > I agree. But I still don't see why Github is better than Savannah for > projects like ours as it sounds about the same. > > > If the only real main difference is needing approval to work on stuff, I'd > say Github is the way to go. If that didn't convince you, consider that Tom > Lieber also loves (loves, loves) Git... > > > Yours, > Kas. > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > > > > > ---------- Weitergeleitete Nachricht ---------- > From: Tomtom <tomtom(a)herbesfolles.org> > To: chuck-users <chuck-users(a)lists.cs.princeton.edu> > Date: Fri, 08 Apr 2011 08:45:51 +0200 > Subject: Re: [chuck-users] controlling individual chuck patches > Maybe you can use a MidiIn object for each of your shreds and pass some > different CC numbers to each of them. > > tom > > Excerpts from Timothy Leonido's message of ven. avril 08 01:50:32 +0200 > 2011: > > hello, > > > > could anyone offer advice on controlling individual chuck patches with an > > external device? currently my mode of operation is to add several shreds > > and control their parameters with maudi sliders (buf.rate, reverb, delay, > > gain), but i'd prefer to use an external controller. > > > > i have an 8 channel alesis mixer with usb-- could this help to answer my > > question? please let me know if you have any controllers in mind, and > also > > which section of the manual is best to read for making these connections. > > > > thank you! > > > > tim > > > > ---------- Weitergeleitete Nachricht ---------- > From: Harald Gutsche <hg42(a)gmx.net> > To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> > Date: Fri, 8 Apr 2011 08:54:55 +0200 > Subject: Re: [chuck-users] Hello and the state of ChucK question > > people can fork off from the main ChucK branch, tinker around, and if > they do > > something cool, they can request that it be merged back in > > Having a simple central repo, everyone can work on any number of local > forks of the project and work on them. > Especially with git or mercurial it is very easy to have several > branches around (in the same or in different working directories) and > push/pull/merge between them. > > When something gets ready to be integrated in the main project, it can > be send as patch to one of the main developers. > This is where github (and now savannah?) adds a different workflow. > First, the main developers can integrate patches themself, without the > fork developer sending them. > So it can be used as pull model instead of push model. > > But, on the other hand, as long as there is no request for > integration, the changes in the fork accumulate. > Integration of many changes at once can be very annoying, because > there will be many conflicts in the merge process. > > If the fork developer tries to make a small patch for integration, he > will try to make this easy, because he wants to convince the main > developers. > The main developers have to do the integration work. > > If the fork developer works on his own branch for a longer time, the > fork can easily drift away from the main branch. > But, if the fork developer regularly integrates changes from the main > branch, he does the main integration work. > > One advantage of a system like github is the public fork repository. > The fork also gets a community process, so the code is reviewed and > tested and discussed by the community, before it makes it's way to the > main branch. Even the main developers can add tips and solutions to > the fork, also to make it better fitting to the main branch. > > So, at the end, all depends on the way people work together. Each > model has it's advantages and disadvantages. > I think a github like system should especially be used, if the fork is > a bigger one, e.g. changing basic structures leading to changes in > many files of the project. > > > > ---------- Weitergeleitete Nachricht ---------- > From: Kassen <signal.automatique(a)gmail.com> > To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> > Date: Fri, 8 Apr 2011 10:02:34 +0200 > Subject: Re: [chuck-users] controlling individual chuck patches > Tim; > > >> could anyone offer advice on controlling individual chuck patches with an >> external device? currently my mode of operation is to add several shreds >> and control their parameters with maudi sliders (buf.rate, reverb, delay, >> gain), but i'd prefer to use an external controller. >> >> i have an 8 channel alesis mixer with usb-- could this help to answer my >> question? please let me know if you have any controllers in mind, and also >> which section of the manual is best to read for making these connections. >> >> >> > Yes! And it's loads of fun. > > These days are good ones for tinkering musicians; lots of interesting MIDI > controllers are getting released and music games (which have nice > controllers) have apparently gotten over their prime popularity-wise leaving > many controllers to the bargains bin. > > Go to your local second hand store or games shop bargain section. Find a > interesting looking controller with a USB plug, if you find something > especially exciting with a Playstation plug (or similar) find it a converter > to USB. Essentially all game controllers with USB plugs will conform to the > "HID" (Human Interface Device) standards, these should work everywhere > without a need for extra drivers. You can get a MIDI one too, but those are > most often more expensive and also less exciting (at least to me), they may > come with nice leds that can blink though. > > Plug it into your computer (on Windows you may now need to hit "ok" and > "continue" a few times). > > Open the folder in the /examples/ dir that deals with hid. These are quite > clear. Use those to figure out what kind of data you can get out of it. If > you found a MIDI controller instead use the MIDI folder, of course. > > Write a file containing UGen definitions at the top, then a Shred that > deals with the controller, then use the main shred to deal with generating > sounds (for example keeping track of a sequence). Use extra shreds if you > found multiple controllers. You can mix MIDI and HID ones if you like, one > per shred. If needed borrow code from the HID example for the one shred, and > code from examples that generate sound for the other. A good "mapping" > between the controller and the sound will likely be more important than a > complex sound, if in doubt; keep it simple. If in doubt; try to not use > feedback on the computer screen. > > Tweak this until it sounds good and seems expressive. > > Practice. > > Presto; within two days and 20 bucks you have a completely new instrument. > > Optional; look for other musicians and test your new instrument by jamming > with them. > Optional; play gigs using this as soon as possible and make notes of what > works well and what doesn't. > Optional; get addicted to finding cheap and unusual controllers, fill a > cupboard with those. > > Good luck! > Kas. > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > >

3 2

Hello and the state of ChucK question
by Krzysztof Trzewiczek 08 Apr '11

08 Apr '11

Hi everyone, I'm new to the list, so a word about me. I'm a software developer in Open Government field and musician focused on experimental and concrete music working from time to time with interactive technologies in dance and theatre. I'm heavily interested in ChucK future development. I come from Poland. Hello everyone ChucKing around!! My question is about the current state and future plans for ChucK. I'm interested especially in: 1. who is responsible for the ChucK website and is it possible to help him/her somehow to make it up to date (documentation, download and install information, some info about the current state, maybe some roadmap)? I'll be happy to spend some free time (not much of it, but a few hours a week for the beginning could be enough) to work on it. 2. is there any mechanism for implementing additional functionality (let say Perlin Noise) directly in ChucK to become a part of ChucK the way Quarks work in SuperCollider? Or the only way of sharing with others is just giving the code and then adding it to the chuck call like: $ chuck-alsa Perlin MyStuff1 MyStuff2 3. is there anyone to expand the developers guide a bit? I'm not a C++ guy and will not implement closures as a new feature in ChucK, but I could write some extensions in C (if not possible in ChucK as in point 2) and attach it to the language. The documentation though is really hard for not advanced programmer and C person (this C++ syntax scares me a lot ;)). 4. will ChucK be developed in future and is there any roadmap for it? All the best from far Poland, trzewiczek ChucK => now; -------------

14 27

controlling individual chuck patches
by Timothy Leonido 08 Apr '11

08 Apr '11

hello, could anyone offer advice on controlling individual chuck patches with an external device? currently my mode of operation is to add several shreds and control their parameters with maudi sliders (buf.rate, reverb, delay, gain), but i'd prefer to use an external controller. i have an 8 channel alesis mixer with usb-- could this help to answer my question? please let me know if you have any controllers in mind, and also which section of the manual is best to read for making these connections. thank you! tim

5 4

Wekinator
by Rebecca Fiebrink 08 Apr '11

08 Apr '11

>> >> ? ?http://wekinator.cs.princeton.edu/ > > Every time Ge drops by this mailing list, it feels like a drive-by. > > This is awesome! Why haven't we heard about it before? A lot of us > are doing similar things (Monome, iPhone/iPad, Android, > OpenKinect/OpenNI, game controllers <--> OSC <--> ChucK, Processing, > mlrv, PD) and probably could have been helpful in its development. Thanks for the shout-out, Ge, and for the interest, Michael. In short, you haven't heard about Wekinator because I was nose-deep in dissertation work until quite recently. The Wekinator is software I built during my recent PhD at Princeton, and it's meant to enable composers and musicians to more easily use machine learning to create interactive systems. (Please see the website for more info: http://wekinator.cs.princeton.edu/) The software is currently in a stable state, and it's usable by anyone who wants to control ChucK, Processing, Unity, Ableton, or pretty much anything else that can be controlled by a stream of OSC messages. These audio/video/etc. systems can be controlled by gesture (Kinect, Arduino, USB game controllers, webcam, ...), audio (e.g. using ChucK audio feature extractors, Max/MSP analyzer~, etc.), or anything else that can extract information about human actions in real-time and pass it to Wekinator via OSC. The software will continue to evolve. There are some architectural changes which must happen soon, but if anyone is looking to help with development, there are a few areas where I see room for collaboration: - UI (to keep this cross-platform, my plan is to stay in Java, using JavaFX + processing; that said, the UI needs an overhaul) - Documentation (READMEs, FAQ, and in-app help) - Examples (e.g., putting together a nice repository of code examples of ChucK, Max/MSP, Ableton, Processing, etc. being driven by Wekinator) - Determining what is necessary for tighter integration into Max/MSP (e.g. using Jamoma framework), with working examples for our Max-loving friends Additionally, I'm very interested in hearing suggestions, bug reports, and feature requests from people who are actively using Wekinator. From the beginning, the software has been driven by the ideas of people actually using it to make music, and it's become a much better project as a result. Lastly, if this project interests you at all, please consider joining the Wekinator mailing list at http://groups.google.com/group/wekinator-users?pli=1. That's the best forum to share your ideas, bugs, questions, etc. Best, Rebecca

3 3