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

Why do child shreds get killed?
by Robin Davies 06 Sep '05

06 Sep '05

Currently, if a shred terminates, all of its child shreds get terminated as well. This raises the following interesting question: why? Honestly, from a user's perspective, I can't think of a compelling use of this feature. Whether there are internal implementation issues that motivate this feature or not is a separate question, I guess; but I can't really think of a good reason to terminate child shreds from an implementation perspective, either. (Unless you're relying on shred termination to garbage collect). On the other hand, I can think of very compelling reasons why shreds should not outlive their parents. I've been bitten by this several times - by shreds silently being terminated because parent shreds have terminated. Here's my compelling use case for allowing shreds to outlive their parents. I spent the weekend playing with chuck. With audio languages (CSound, SAOL, Music-N, &c), one of the constant challenges is how to provide clean and modular integration between expensive control-rate operations, fast audio-rate operations, and external events. Having had exposure to MusicN based languages that provide control-rate processing, I thought I'd try using the control concept in chuck. Here's the theory: write an IInstrument abstract class that provides an abstract Tick() method which gets called at control-rate. Output of the instrument is placed on the Instrument.Out ugen so that instruments can then be routed onto an external output. Implementations of IInstrument then call (for example) StartTick(16::samp), which causes the Tick method to be called every 16 samples on a separate shred. This works very well. The end result: an AnalogSynth class, implementing IInstrument, that provides two two control-rate lfos, two control-rate envelopes, one band-limited oscillator ugen (private build coming to a Chuck near you soon) and a filter ugen. AnalogSynth runs about 12 voices in realtime on my lowly 800Mhz home machine, without any real attention to optimization! So far so good. The purpose of the Tick() processing is,of course, to run the LFOs and ADSrs at reduced rate (every 16 samples), and then perform all of the expensive routing of lfos and ADSrs outputs onto UGens at something less than audio rate. Well. It does work very well, as long as I drive the IInstrument from midi or OSC input. It fails spectacularly if notes are triggered from temporary shreds when writing scores in Chuck. Consider the following: function void PlayNote(IInstrument instr, float midNote, dur length) { instr.NoteOn(midiNote,1.0); length => now; instr.NoteOff(midiNote); } spork ~ PlayNote(analogSynth, Midi.C4, 1.5::beat); This fails, spectacularly. Internally, the Tick shred gets started up, but it shuts down as soon as the PlayNote shred terminates (causing the note to get stuck). In retrospect, I guess the answer is to create a tick shred at the time the instrument is created, and then use events to synchronize the tick shred. But that's just so... so... inconvenient. Or another approach: make PlayNote wait forever, after the note off. But that's just so... so.... ugly. Hmm. Or maybe a WaitForAllChildThreadsToDie() function. The event solution also runs into significant problems with controlling the first tick after startup. Consider: An IInstrument receives a note-on event. It initializes all of it's control rate state variables (reseting ADSRs, for example). Now it needs to start the tick shred up. So it signals an event. The question is this: will the tick shred run in the current cycle or not? If it doesn't then StartTick() should call IInstrument.Tick(). But whether the shred ran in the current thread or not is non-deterministic. It depends on whether the shreduler ran the current thread or the tick thread first for the current value of Now. Even worse. The tick shred can no longer perform "16::samp => now", because the noteon event may have arrived at some non-modulo-8 mutiple of now::samp. So this approach requires complicated and expensive handshaking between the Instrument and its tick thread to get everything lined up and operating deterministically. (<thinking>... this is doable, and probably the way I'll go) Or another use-case for the same: function void PlayTheWholeSong() { Spork ~ PlayBassMotif1(); Spork ~ PlayMelody1(); 12::beat => now; Spork ~ PlayBassMotif1(); Spork ~ PlayMelody2(); // oops. No more bass motif or melody shred. } The feature request; maybe a way to let shreds re-assign their parent shred to the root shred. That would be nice. Or maybe just don't terminate child shreds at all. Robin Davies Lead Software Developer Quest Web Reports Quest Software 613.270.1569 Identity Management for the Windows Enterprise <http://wm.quest.com/reg/marketing/landing/identitymanagement/> : See how Quest helps you leverage your existing investment to solve the identity management challenge!

3 2

OTF not working...
by Furlan Primus 04 Sep '05

04 Sep '05

Time-stamp: <2005-09-03 19:09:47 flp> Hi, While testing the examples, following the directions in otf_01.ck I opened a second tab / terminal and entered "chuck + otf_02.ck" which returned "operation sucsessful" I switched to the first terminal and got: [flp@magicbox 0002]$ chuck --loop [chuck](VM): sporking incoming shred: 1 (otf_01.ck)... *** Fatal error : sizeof (off_t) != sizeof (sf_count_t) *** This means that libsndfile was not configured correctly. ========================= What am I doing wrong? ChucK was compiled sucessfully AFAIK. TIA ciao, furlan -- Home: http://flprim.us/index.html "The cure for boredom is curiosity. There is no cure for curiosity." -- Dorothy Parker

2 2

ADSR envelope
by Manfred Brockhaus 02 Sep '05

02 Sep '05

I'd like to know the following which I didn't find in the documentation. - default values of A,D,S and R - default rates of A,D and R Also, I've noticed that user defined value assignments if any must be written in the order A-D-S-R to work properly. Is this true? -mb

1 0

Re: [chuck-users] OSC receiver
by Manfred Brockhaus 31 Aug '05

31 Aug '05

On Aug 31, 2005, at 10:49 AM, Philip Davidson wrote: > process removal uses the shred number, rather than the name > -see the VM documentation for retreiving this using machine.status Thanks, I got it. Works perfectly. Just found a minor issue related to OSC. When receiving an OSC event containing a string parameter (eg. "abc") I get an additional message add string |abc| ( 4 ) Looks like some debugging code... -mb

2 1

Re: [chuck-users] OSC receiver
by Manfred Brockhaus 31 Aug '05

31 Aug '05

On Aug 31, 2005, at 8:31 AM, Philip Davidson wrote: > This is a slightly different issue - you appear to be launching two > separate chuck VM's - for instance > chuck program1.ck in a terminal window, > and then 'chuck program2.ck ' in another terminal. > > the chuck VM binds to port 8888 by default in order to listen for > incoming VM messages on the same machine, or over the network. > If two VM's are launched, the second won't be able to make the > connection, and thus prints the error message. > > by using the > %chuck --loop > option, chuck will background itself and wait for incoming message, and > you can then use > %chuck +program.ck > to add a new program to the VM Thanks for the explanation. Makes sense. However, removing the program doesn't seem to work for me. When using %chuck - program.ck I get the message [chuck](VM): cannot remove: no shred with id 0... -mb

2 1

OSC receiver
by Manfred Brockhaus 30 Aug '05

30 Aug '05

Hi, congratulations on the new release! I'm on OS X and in particular interested to use MIDI and OSC events. So far MIDI in/out seems to work fine here. OSC send works too, but with the example 'opensound_demo_recv.ck' I get an error message: class 'OSC_Recv' has no member 'event'. -mb

2 1

[solution] compile and link problem under FC3...
by Furlan Primus 28 Aug '05

28 Aug '05

Hi, Earlier today I had trouble compiling and linking the 'Dracula' version of ChucK. After some emails to Ge Wang a solution was found. The problem was that when compiling for linux-alsa it was looking for a file called sndfile.h and that file was NOT on my system as I have a precompiled version of libsndfile. The solution was to follow the directions in the makefile.alsa file: #----------------------------------------------------------------------------- # by default, ChucK on linux needs libsndfile... # comment the next 3 lines to use a pre-configured libsndfile #----------------------------------------------------------------------------- # FLAGS+= -D__CK_SNDFILE_NATIVE__ # LIBS+= -lsndfile # SF_OBJ= Once that was commented out (as above) the compilation & linking went without any further delay. Maybe this will assist someone else who experiences a similar problem. ciao, furlan -- Home: http://flprim.us/index.html Ambition is a poor excuse for not having sense enough to be lazy. -- Milan Kundera

2 1

Re: chuck Digest, Vol 18, Issue 3
by Jeffrey Treviño 28 Aug '05

28 Aug '05

Congratulations on the release! I look forward to learning all the new stuff you've made. A quick question that I need to answer for a potential Chuck project: is there a Chuck function that returns today's date in some form? I remember a built-in function in C that did this–is there a Chuck equivalent? Again, excellent work and congrats on the release. As soon as the Audicle gets set, I can sit out front with a projector and amaze unwitting passersby. --Jeff On Aug 25, 2005, at 9:00 AM, chuck-request(a)lists.cs.princeton.edu wrote: > Send chuck mailing list submissions to > chuck(a)lists.cs.princeton.edu > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.cs.princeton.edu/mailman/listinfo/chuck > or, via email, send a message with subject or body 'help' to > chuck-request(a)lists.cs.princeton.edu > > You can reach the person managing the list at > chuck-owner(a)lists.cs.princeton.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of chuck digest..." > Today's Topics: > > 1. version 1.2.0.0 (dracula) released (Ge Wang) > 2. spork ~ chuck-users ( new mailing_list + more ) (Ge Wang) > > From: Ge Wang <gewang(a)CS.Princeton.EDU> > Date: August 25, 2005 6:07:57 AM PDT > To: ChucK Audio Programming Language Mailing List > <chuck(a)lists.cs.princeton.edu> > Subject: [chuck] version 1.2.0.0 (dracula) released > > > Dear All, > > chuck-1.2.0.0 is released. (Sorry.) This is the "v2" major release. > Additions include arrays, objects and classes, events, and more. A > full list of new and updated features can be found at the end of this > email. > > http://chuck.cs.princeton.edu/ > > We have also put together a draft of a language specification > (finally). It is not complete yet and will be improved as (real) time > is advanced: > > http://chuck.cs.princeton.edu/doc/language/ > > We have been testing this release along the way. However, since this > is the initial release, there is probably a healthy amount of > egregious bugs! Please let us know if you run into anything fishy > (email one of us directly, post to chuck-dev or the newly created > chuck-users list). Same goes for the documentation. Actually, any > type of feedback would be greatly appreciated. > > Many thanks to the great people who have contributed ideas, code, and > time to this release! Thanks to everyone for being so patient with > this release. > > Development shall continue as we fix the bugs, add new features (and > more bugs). > > Please let us know if you run into any problems. HappY ChucKing! > > Best, > ChucK Team > (Perry, Ananya, Phil, Adam, Ajay, Ge ...) > > --- > 1.2.0.0 > > SYNTAX and OPERATORS: > - (added) +=>, operator : 2 +=> i; (also) -=>, *=>, /=>, %=> > - (added) @=> for explicit assignment > this is the only way to make object reference assignments > - (added) implicit int to float casting > - (changed) cast now look like: 1.1 $ (int) => int i; > - (added) function call by chucking : > // call > (1,4) => math.rand2f => result; > // same as > math.rand2f(1,4) => result; > > LANGUAGE: > - (fixed) type system for existing types > - (added) forward lookup of classes and functions (mutual recursion) > - (added) stack overflow detection for massive recursion > > DOCUMENTATION: > - (added) language specification: > http://chuck.cs.princeton.edu/doc/language > > COMMAND-LINE: > - (added) --probe prints all audio and MIDI devices > - (added) --log or --verbose logs compiler and virtual machine > - (added) --logN or --verboseN multi level logging > 1 - least verbose > 10 - most verbose > > OBJECTS: > - (added) 'class' definitions : class X { int i; } > - (added) 'extends' keyword : class Y extends Event { int i; } > - (added) virtual/polymorphic inheritance > - (added) added pre-constructors - code at class level > gets run when object is instantiated > - (added) function overloading : > class X { fun void foo() { } fun void foo( int y ) { } } > - (added) base classes (can be extended): > Object, Event, UGen > see below > - (added) base classes (cannot be extended): > array, string > see below > - (added) member data > - (added) static data > - (added) member functions > - (added) static functions > > EVENTS: > - (added) base Event class : Event e; > can be used directly > can be extended to custom events > (see one_event_many_shreds.ck) > - (added) waiting on event, chuck to now : > e => now; // wait on e > - (added) e.signal() wakes up 1 shred, if any > - (added) e.broadcast() wakes up all shreds waiting on e > - (added) class MidiEvent (see gomidi2.ck) > alternative to polling. > - (added) class OSCEvent > > ARRAYS: > - (added) arrays : int a[10]; float b[20]; Event e[2]; > - (added) multidimensional arrays : int a[2][2][2]; > - (added) associative arrays : int a[10]; 0 => a["foo"]; > all arrays are both int-indexed and associative > - (added) array initialization : [ 1, 2, 3 ] @=> int a[]; > - (added) .cap() for array capacity > - (added) .find() test if item is associative array > - (added) .erase() erase item in associative array > > UGENS: > - (added) class UGen > can be extended > - (changed) all ugen parameters are now also functions: > // set freq > 440 => s.freq => val; > // same as... > s.freq( 440 ) => val; > - (changed) left-most parameters must now be called as functions > // no longer valid > f.freq => float val; > // valid > f.freq() => float val; > // still ok > 440 => s.freq => float val; > > SHREDS: > - (added) class Shred > - (added) .yield() .id() > > STRINGS: > - (added) class string > > AUDIO: > - (added) stereo > all stereo unit generators have .left, .right, .pan functions > - (changed) stereo ugen: dac (2 in, 2 out) > - (changed) stereo ugen: adc (0 in, 2 out) > - (added) stereo ugen: pan2 take mono or stereo input and pans > - (added) stereo ugen: mix2 mix stereo input into mono > > > > > > From: Ge Wang <gewang(a)CS.Princeton.EDU> > Date: August 25, 2005 6:12:07 AM PDT > To: ChucK Audio Programming Language Mailing List > <chuck(a)lists.cs.princeton.edu> > Subject: [chuck] spork ~ chuck-users ( new mailing_list + more ) > > > Dear All, > > Along with the new release, we have made a new mailing list > (chuck-users), intended for specific questions and discussions about > using chuck. This list (chuck) will (soon) become a moderated, > low-traffic mailing list intended for updates, announcements, > tutorials, and low-bandwidth discussions. > > Hopefully the folks that are interested in chuck can remain on (chuck) > without being potentially spammed too much, and those that have > specific questions can fire away on (chuck-users) with a clean > conscience! > > Additionally, we have been graciously given permission to abuse an > entity called 'soup kitchen'. It is the state-of-the-art in > anti-social networking. It contains many nice features (all > conversations are by default world-readable, optional email > notification of new replies to topics, and is rather elegant) that may > be to useful as a semi-realtime semi-anonymous forum. The author, > Visnu Pitiyanuvath, will work with us to further enhance the site to > make it more useful and fun. > > Links to all the lists and soup kitchen can be found here: > > http://chuck.cs.princeton.edu/community.html > > Join, if you like. Have fun! > > Best, > ChucK Team > > > > > _______________________________________________ > chuck mailing list > chuck(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck

2 1

load_dll from chuck code?
by Robin Davies 28 Aug '05

28 Aug '05

I'm very excited to see Chuck 1.2.2.0, and I'm eager to start tweaking. I'd particularly like to get started on writing external C++ UGens for Chuck. I own source for some particularly useful functions that I'd love to get tied into Chuck (intention to donate as an external project), but I can't seem to find the procedure for loading an external dll either from Chuck code, or from the command-line, or otherwise. All the code seems to be there to load an external DLL, but it doesn't seem to be hooked up to anything yet. Am I missing something? Are there any immediate plans to expose this, or should I get busy hacking away? UGens that I'm interested in implementing: - hosting VST plugins in chuck (a huge priority for me, have source code, will integrate, if nobody else is doing this) - maybe Chuck as a VST plugin (not a huge priority for me) - Some more basic instrument building blocks for ugens, band-limited waveforms, particulary. - High-quality sample interpolators. Is anyone else out there doing 3rd-party development for Chuck yet? I'd be interested in sharing plans and priorities. Regards, Robin Davies

2 1

OSC utilies/programs for Win32?
by Robin Davies 26 Aug '05

26 Aug '05

Does anyone know of a source of OpenSoundControl utilities for Win32? Something to test-drive chuck's support for OSC would be great. Something to do basic sequencing would be greater. Something to drive chuck from buildable GUI would be greater still. Regards, Robin Davies

2 1