
Greetings fellow ChucKists, Here is a (not so) quick summary/warning about upcoming changes in chuck-1.2.0.7, to be released probably next week. what it don't got: - garbage collection is still on a holding pattern and will not be in 1.2.0.7 - the long-overdue string operations, unfortunately, insist on waiting for garbage collection, and also will not in 1.2.0.7 - file i/o api's have been implemented (thanks to Martin Robinson), will be included soon but not in 1.2.0.7 Sorry about that. Now that we've apologized about what's not in the release, it's time to apologize about what is. Due to recent discussions on this list, two sets of changes and additions have been made. We want to preview them here to get feedback before setting them in concrete. API deprecations. Our discussion more or less determined that it's best to unify the naming scheming now before things get further out of hand, particularly for UGen names and such. So the current solution deprecates the object names in question and provides more consistent naming. By default, when a deprecated name, such as 'sinosc', is encountered, a warning will be issued, such as 'line(1): deprecated: 'sinosc' --> use: 'SinOsc''. The behavior should be otherwise unchanged. In other words the program should still work as before. We've also added a --deprecate flag that allows you to stop, warn, or ignore upon encountering a deprecated item. The default is 'warn'. Here are the objects deprecated so far, and their replacements: - (api) deprecated --> new classes -------------------------- sinosc --> SinOsc triosc --> TriOsc sqrosc --> SqrOsc sawosc --> SawOsc pulseosc --> PulseOsc phasor --> Phasor osc --> Osc noise --> Noise cnoise --> CNoise impulse --> Impulse step --> Step halfrect --> HalfRect fullrect --> FullRect gain --> Gain zerox --> ZeroX delayp --> DelayP sndbuf --> SndBuf pan2 --> Pan2 mix2 --> Mix2 onepole --> OnePole onezero --> OneZero polezero --> PoleZero twopole --> TwoPole twozero --> TwoZero biquad --> BiQuad std --> Std math --> Math machine --> Machine A few more UGen's. From another discussion on list, also by popular demand, it seems convenient to have out-of-the-box filters, in addition to general 1st and 2nd order filters (OnePole/Zero, BiQuad, etc.). We've examined and plundered from Csound, SC, and PD source code, and chuckified a few UGen's. We are going to do this in installments, adding various UGens every release. In 1.2.0.7, They include: LPF : lowpass filter (2nd order butterworth) (also with cutoff resonance control) HPF : highpass filter (2nd order butterworth) (also with cutoff resonance control) BPF : bandpass filter (2nd order butterworth) BRF : bandreject filter (2nd order butterworth) ResonZ : resonant filter (BiQuad with equal-gain zeros) FilterBasic : base class to above filters Of course, all of these can be designed and implemented using existing filters, but these provide direct access to cutoff and Q out-of-the-box and behave in a familiar um Butterworthy way. (More are on the way) We'd appreciate your feedback on these. For example: 1. api changes are in general, not reasons for group celebration. what can be done to further smooth the transition? 2. new naming optimal? 3. anything else Thanks! Best, chuck team

Ge wrote;
2. new naming optimal?
I'd still prefer all lower case or even being case insensitive for everything but user-defined stuff. I admit that my reasons here are mostly personal; once I get into the frame of mind to use caps in writing I tend to start lines with a capital which makes the compiler complain which in turn anoys me. Pilot error, for sure, but it's something that I found happens. I'd be interested in hearing wether that's just my own little brain or some more universal patern. More universally; I don't find caps add any real meaning here though I suppose using capitalisation for Ugen and class names, then lowercase for instances might be usefull to those acustomed to that convention, personally I find it confusing (that might again be just me). Clearly; doing that *would* break existing code while the current plan won't. Also; sticking to the STK conventions has some merrits in that it should make it more clear how some yet under-documented ChucK bits link to the existing STK documentation. So; it's not my own first choice but now it's consistent. Being consistent is good for learning syntax quickly and it decreases confusion. One area I'd like to include in this is ugen parameters. Right now they are; LikeThis.likeThis for STK ones and LikeThis.like_this The Ugens that are made up of two words get named with two caps for the name, and either a cap for the second name for the STK ones and all lowercase for the ChucK ones. Examples; Flute.startBlowing (from the STK) and SinOsc.sfreq (ChucK, proposed new usage) Had SinOsc been in the STK then it probably would have been; SinOsc.sFreq This would be more consistent, and probably should be done if we are going to have consistency based on STK conventions. Another case is SndBuf.phase_offset which also has a different behaviour (but I could only find one example like that). With that being the only underscore in sight I think I'd propose; SndBuf.phaseOffset Fortunately this affects only a few ugens since the native ChucK stuff tends to be basic building block stuff and only a few of the parameters have complicated two-part names. If we are going to have a wave of making stuff consistend I think I'd like to include the controll parameters as well. So, to conclude; I'd prefer all lowercase myself but nobody else spoke out for that so I might be alone. In that case I'd be very happy with the new consistencyand clarity and the elimination of the need to keep track of what bit came from where. I'd also like toput .sfreq and .phase_offset on the list of things to be unified. The new filters are great news, lookingforward to playing with them. All of this is just my own thoughts and I'm dyslexic so basing anything on my sugestions about writing may or may not lead to explosions, mild nausia, getting ex-communicated or sudden death. Yours, Kas.

Hi Matt and Kassen!
I'd still prefer all lower case or even being case insensitive for everything but user-defined stuff.
Some of us (me, for one) have a liking to lower case (and underscores) for some reason, which probably contributed to the existing lower case naming. However, we also felt that uppercase names for other stuff (Object, Event, UGen, STK UGens) was best, too. As we've all noted, this isn't so good for consistency. Another case of on-the-fly API design... After trying out the new uppercase system for a while (I had to convert all the examples and test them), it did grow on me. Either that or I was delusional...
So; it's not my own first choice but now it's consistent. Being consistent is good for learning syntax quickly and it decreases confusion.
Yup, I guess we should see in coming months how this works out.
One area I'd like to include in this is ugen parameters. Right now they are;
LikeThis.likeThis
for STK ones and
LikeThis.like_this
Good idea. Since we are making api changes, we should update these as well. Thoughts from others?
All of this is just my own thoughts and I'm dyslexic so basing anything on my sugestions about writing may or may not lead to explosions, mild nausia, getting ex-communicated or sudden death.
Those risks reminds of something... oh yeah: chuck. Best, Ge!

On Sun, 10 Sep 2006, Ge Wang wrote:
Some of us (me, for one) have a liking to lower case (and underscores)
i ThiNk aLL yOu kwAZeE peopLe In pRInCEtOn haVe SPaSTic SHIft-KeY fINgeRs. (Or maybe you're just pinin' for the happy nEXt-machine days of yore.) "ChucK" (or is it "cHUcK"? -- I keep forgetting) indeed! brad http://music.columbia.edu/~brad

Ge Wang escribió:
Hi Matt and Kassen!
I'd still prefer all lower case or even being case insensitive for everything but user-defined stuff.
Some of us (me, for one) have a liking to lower case (and underscores) for some reason, which probably contributed to the existing lower case naming. However, we also felt that uppercase names for other stuff (Object, Event, UGen, STK UGens) was best, too. As we've all noted, this isn't so good for consistency. Another case of on-the-fly API design... After trying out the new uppercase system for a while (I had to convert all the examples and test them), it did grow on me. Either that or I was delusional...
I'm totally the opposite, I like upperCase and don't like underscores, but can get used to any convention, so I'm all for convention, and the one that you suggested seems nice to me. For that respect:
One area I'd like to include in this is ugen parameters. Right now they are;
LikeThis.likeThis
for STK ones and
LikeThis.like_this
Good idea. Since we are making api changes, we should update these as well. Thoughts from others?
I agree with that. It's better to do it now than later. Best! -- jesús gollonet http://www.jesusgollonet.com/blog

Hi Ge,
I am 100% in agreement with these decisions. The naming scheme is
logical, and I think the capitals make things easiest to read.
The additional of filters is quite nice. I have been working with a
lot of data processing in Pure Data, and I'm extremely happy that
ChucK now has both nice oscillators, and filters out of the box. Not
really being a DSP person per se, the lack of these things in PD is
somewhat annoying. Anyway, this means I'll probably be trying some
things where PD will send the data to ChucK using OSC - this should
work quite nicely.
If I was going to request three additional "bread and butter" UGen's,
I'd ask for
1. Compressor
2. Limiter
3. TubeOverdrive (ie. analog simulation)
I'd also love to see a port of the destroyFX stuff, I think their
source code is available:
http://destroyfx.smartelectronix.com/
~David
On 9/9/06, Ge Wang
Greetings fellow ChucKists,
Here is a (not so) quick summary/warning about upcoming changes in chuck-1.2.0.7, to be released probably next week.
what it don't got: - garbage collection is still on a holding pattern and will not be in 1.2.0.7 - the long-overdue string operations, unfortunately, insist on waiting for garbage collection, and also will not in 1.2.0.7 - file i/o api's have been implemented (thanks to Martin Robinson), will be included soon but not in 1.2.0.7 Sorry about that.
Now that we've apologized about what's not in the release, it's time to apologize about what is. Due to recent discussions on this list, two sets of changes and additions have been made. We want to preview them here to get feedback before setting them in concrete.
API deprecations. Our discussion more or less determined that it's best to unify the naming scheming now before things get further out of hand, particularly for UGen names and such. So the current solution deprecates the object names in question and provides more consistent naming. By default, when a deprecated name, such as 'sinosc', is encountered, a warning will be issued, such as 'line(1): deprecated: 'sinosc' --> use: 'SinOsc''. The behavior should be otherwise unchanged. In other words the program should still work as before. We've also added a --deprecate flag that allows you to stop, warn, or ignore upon encountering a deprecated item. The default is 'warn'.
Here are the objects deprecated so far, and their replacements:
- (api) deprecated --> new classes -------------------------- sinosc --> SinOsc triosc --> TriOsc sqrosc --> SqrOsc sawosc --> SawOsc pulseosc --> PulseOsc phasor --> Phasor osc --> Osc noise --> Noise cnoise --> CNoise impulse --> Impulse step --> Step halfrect --> HalfRect fullrect --> FullRect gain --> Gain zerox --> ZeroX delayp --> DelayP sndbuf --> SndBuf pan2 --> Pan2 mix2 --> Mix2 onepole --> OnePole onezero --> OneZero polezero --> PoleZero twopole --> TwoPole twozero --> TwoZero biquad --> BiQuad
std --> Std math --> Math machine --> Machine
A few more UGen's. From another discussion on list, also by popular demand, it seems convenient to have out-of-the-box filters, in addition to general 1st and 2nd order filters (OnePole/Zero, BiQuad, etc.). We've examined and plundered from Csound, SC, and PD source code, and chuckified a few UGen's. We are going to do this in installments, adding various UGens every release. In 1.2.0.7, They include:
LPF : lowpass filter (2nd order butterworth) (also with cutoff resonance control) HPF : highpass filter (2nd order butterworth) (also with cutoff resonance control) BPF : bandpass filter (2nd order butterworth) BRF : bandreject filter (2nd order butterworth) ResonZ : resonant filter (BiQuad with equal-gain zeros) FilterBasic : base class to above filters
Of course, all of these can be designed and implemented using existing filters, but these provide direct access to cutoff and Q out-of-the-box and behave in a familiar um Butterworthy way. (More are on the way)
We'd appreciate your feedback on these. For example: 1. api changes are in general, not reasons for group celebration. what can be done to further smooth the transition? 2. new naming optimal? 3. anything else
Thanks!
Best, chuck team
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Hi all, I am testing how ADSR UGen works and I am still not sure what do parameters to (time)members (attackTime, decayTime, etc) mean. Are they automatically casted to seconds? For instance: ADSR env; env.attackTime( .1 ); Does this mean that attackTime is 100::ms? I have tried to understand how ADSR works with the following patch: sinosc s => ADSR env => dac; env.attackTime( .01 ); env.releaseTime( 1 ); env.decayTime( 0 ); 1=>env.keyOn; <<< "begin note_on", env.state(), now/ms>>>; while( !env.state() ) { 1::samp=>now; if( env.state() ) <<< "end_of_attack", env.state(), now/ms>>>; } 1=>env.keyOff; <<< "begin note_off", env.state(), now/ms>>>; while( env.state() == 1 ) { 1::samp=>now; } <<< "end_of_decay", env.state(), now/ms>>>; while( env.state() == 2 ) { 1::samp=>now; } <<< "end_of_sustain", env.state(), now/ms>>>; while( env.state() == 3 ) { 1::samp=>now; } <<< "end_of_release", env.state(), now/ms>>>; while( env.state() != 4 ) { 1::samp=>now; } <<< "done.", env.state(), now/ms>>>; which ouput is the following: begin note_on 0 0.000000 end_of_attack 1 10.000000 begin note_off 3 10.000000 end_of_decay 3 10.000000 end_of_sustain 3 10.000000 end_of_release 4 2010.000000 done. 4 2010.000000 This would bean that attack lasts for 10::ms as env.attackTime() was set to .01. But then I don't understand why release ends at 2010::ms as releaseTime() is set to 1. Note that decayTime is set to zero and there is no sustain, as you can see from the output. Can anybody give me a hand on how to interpret the parameters to ADSR members? Thanks, eduard

Hi Eduard!
I am testing how ADSR UGen works and I am still not sure what do parameters to (time)members (attackTime, decayTime, etc) mean. Are they automatically casted to seconds?
For now, yes. All ADSR times are in seconds. We hope to convert them to dur soon. I added two functions in the meantime: .set( dur a, dur d, float s, dur r ); .set( float a, float d, float s, float r );
begin note_on 0 0.000000 end_of_attack 1 10.000000 begin note_off 3 10.000000 end_of_decay 3 10.000000 end_of_sustain 3 10.000000 end_of_release 4 2010.000000 done. 4 2010.000000
This would bean that attack lasts for 10::ms as env.attackTime() was set to .01. But then I don't understand why release ends at 2010::ms as releaseTime() is set to 1.
Aha. This happens because keyOff() is called before the ADSR is in the sustain state. I've fixed it so that the releaseTime is as expected even if keyOff is called way early: 1010. The changes in CVS and will be included in 1.2.0.7. Thanks! Best, Ge!

Hi,
Aha. This happens because keyOff() is called before the ADSR is in the sustain state. I've fixed it so that the releaseTime is as expected even if keyOff is called way early: 1010.
thanks
The changes in CVS and will be included in 1.2.0.7.
When building chuck from cvs in macintel got the following: make -f makefile.osx bison -dv -b chuck chuck.y gcc -D__MACOSX_CORE__ -O3 -c chuck.tab.c flex -ochuck.yy.c chuck.lex gcc -D__MACOSX_CORE__ -O3 -c chuck.yy.c gcc -D__MACOSX_CORE__ -O3 -c chuck_main.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_errmsg.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_utils.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_symbol.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_table.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_temp.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_absyn.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_type.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_emit.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_frame.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_instr.cpp /usr/include/sys/types.h:86: error: declaration does not declare anything make[1]: *** [chuck_instr.o] Error 1 make: [osx] Error 2 (ignored) No probs on ppc. If I'm not mistaken this was the very same error which happened when building tapestrea (first release) on macintels. any ideas how to fix it? thanks, eduard

Hi Eduard!
When building chuck from cvs in macintel got the following:
gcc -D__MACOSX_CORE__ -O3 -c chuck_instr.cpp /usr/include/sys/types.h:86: error: declaration does not declare anything
This is quite strange. We don't have a macintel around, so we'll try to debug remotely. I checked in a slight change to the offending file, please update and try compiling again? Also: 1. what gcc version on macintel? 2. does the release 1.2.0.6 compile or do you get the same error? Anyone else encounter the same problem? Thanks! Ge!

Hi Ge, same thing after updating, 23:52:39 - :/CHUCK/chuck_dev/src$ make clean rm -f *.o chuck.tab.c chuck.tab.h chuck.yy.c chuck.output 23:52:45 - eaylon@jupiter:/CHUCK/chuck_dev/src$ make osx make -f makefile.osx bison -dv -b chuck chuck.y gcc -D__MACOSX_CORE__ -O3 -c chuck.tab.c flex -ochuck.yy.c chuck.lex gcc -D__MACOSX_CORE__ -O3 -c chuck.yy.c gcc -D__MACOSX_CORE__ -O3 -c chuck_main.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_errmsg.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_utils.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_symbol.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_table.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_temp.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_absyn.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_type.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_emit.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_frame.cpp gcc -D__MACOSX_CORE__ -O3 -c chuck_instr.cpp /usr/include/sys/types.h:86: error: declaration does not declare anything make[1]: *** [chuck_instr.o] Error 1 make: [osx] Error 2 (ignored) ############### gcc version is 4.0.1 ############### 23:52:59 - /CHUCK/chuck_dev/src$ gcc --version i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250) Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ################### chuck-1.2.0.6 builds ok. ################### 23:55:35 - /CHUCK/chuck-1.2.0.6/src$ make clean rm -f *.o chuck.tab.c chuck.tab.h chuck.yy.c chuck.output chuck 23:55:39 - /CHUCK/chuck-1.2.0.6/src$ make osx-intel make -f makefile.osx-intel bison -dv -b chuck chuck.y gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck.tab.c flex -ochuck.yy.c chuck.lex gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck.yy.c gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_absyn.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_parse.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_errmsg.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_frame.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_symbol.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_table.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_utils.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_vm.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_instr.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_scan.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_type.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_emit.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_compile.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_dl.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_oo.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_lang.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_ugen.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_main.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_otf.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_stats.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_bbq.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_shell.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_console.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c chuck_globals.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c digiio_rtaudio.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c hidio_sdl.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c midiio_rtmidi.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c rtaudio.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c rtmidi.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ugen_osc.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ugen_filter.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ugen_stk.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ugen_xxx.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ulib_machine.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ulib_math.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ulib_std.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c ulib_opsc.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_buffers.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_console.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_math.c gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_network.c gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_raw.c gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_string.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_thread.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_xforms.c gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_opsc.cpp gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_hid.c gcc -D__MACOSX_CORE__ -D__INTEL_MAC__ -O3 -c util_sndfile.c g++ -o chuck chuck.tab.o chuck.yy.o chuck_absyn.o chuck_parse.o chuck_errmsg.o chuck_frame.o chuck_symbol.o chuck_table.o chuck_utils.o chuck_vm.o chuck_instr.o chuck_scan.o chuck_type.o chuck_emit.o chuck_compile.o chuck_dl.o chuck_oo.o chuck_lang.o chuck_ugen.o chuck_main.o chuck_otf.o chuck_stats.o chuck_bbq.o chuck_shell.o chuck_console.o chuck_globals.o digiio_rtaudio.o hidio_sdl.o midiio_rtmidi.o rtaudio.o rtmidi.o ugen_osc.o ugen_filter.o ugen_stk.o ugen_xxx.o ulib_machine.o ulib_math.o ulib_std.o ulib_opsc.o util_buffers.o util_console.o util_math.o util_network.o util_raw.o util_string.o util_thread.o util_xforms.o util_opsc.o util_hid.o util_sndfile.o -framework CoreAudio -framework CoreMIDI -framework CoreFoundation -framework IOKit -framework Carbon -lstdc++ -lm ########################## I remember I had the same error when compiling taps for the first time. But then Ananya sent an update and the problem was solved. Below is the email sent at the time: On Jul 29, 2006, at 2:59 AM, Ananya Misra wrote:
There is an updated version of TAPESTREA (version 0.1.0.1) now available:
http://taps.cs.princeton.edu/release/
It fixes some problems we found with the MacOS X executable and also with compiling the code on osx.
If you come across any problems with this version, please let us know.
Thanks.
taps team
On Sep 11, 2006, at 11:06 PM, Ge Wang wrote:
Hi Eduard!
When building chuck from cvs in macintel got the following:
gcc -D__MACOSX_CORE__ -O3 -c chuck_instr.cpp /usr/include/sys/types.h:86: error: declaration does not declare anything
This is quite strange. We don't have a macintel around, so we'll try to debug remotely. I checked in a slight change to the offending file, please update and try compiling again?
Also: 1. what gcc version on macintel? 2. does the release 1.2.0.6 compile or do you get the same error?
Anyone else encounter the same problem?
Thanks!
Ge!
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Hi Eduard and Jukka! I think we've found the "source" of the problem:
23:52:45 - eaylon@jupiter:/CHUCK/chuck_dev/src$ make osx
The CVS source is actually not in src, which has the old v1 code, but in chuck_dev/v2/. Please update in v2 and 'make osx'. Hopefully that should work. We need to do something about src... what a disaster on our part. --- make osx --> compiles for either ppc or intel make osx-ub --> universal binary I think this should allow us to have cake and devour it too. Yum... Please let us know if this works. Best, Ge!

Thanks, that fixes it. Sorry for wasting your time... eduard On Sep 12, 2006, at 3:39 AM, Ge Wang wrote:
Hi Eduard and Jukka!
I think we've found the "source" of the problem:
23:52:45 - eaylon@jupiter:/CHUCK/chuck_dev/src$ make osx
The CVS source is actually not in src, which has the old v1 code, but in chuck_dev/v2/. Please update in v2 and 'make osx'. Hopefully that should work.
We need to do something about src... what a disaster on our part.
---
make osx --> compiles for either ppc or intel make osx-ub --> universal binary
I think this should allow us to have cake and devour it too. Yum...
Please let us know if this works.
Best, Ge!
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Hi Eduard!
Thanks, that fixes it. Sorry for wasting your time...
Not at all. The pleasure of time waste completely belongs to us for putting way outdated stuff in src/ and instead keeping the current image in v2/. I've just removed everything in src/ and left a README pointing visitors to v2/. Did the ADSR work as expected? Best, Ge!

Did the ADSR work as expected?
Yes it did. Thanks. Now that we are speaking about envelopes I'd like to point out (correct me if I am wrong) the fact that Envelope UGen has only 1 time member, meaning attack and release will be always equal. Wouldn't make more sense to be able to define attack and release times separately for an AR envelope? Anyway, it can be accomplished by ADSR without decay nor sustain. Nothing to worry about, just being picky. cheers, eduard

On Sep 11, 2006, at 5:06 PM, Ge Wang wrote:
Hi Eduard!
When building chuck from cvs in macintel got the following:
gcc -D__MACOSX_CORE__ -O3 -c chuck_instr.cpp /usr/include/sys/types.h:86: error: declaration does not declare anything
This is quite strange. We don't have a macintel around, so we'll try to debug remotely. I checked in a slight change to the offending file, please update and try compiling again?
Also: 1. what gcc version on macintel? 2. does the release 1.2.0.6 compile or do you get the same error?
Anyone else encounter the same problem?
I am seeing this, too. First, a disclaimer. I've barely gotten into using ChucK and hadn't looked at source until I heard about this problem. Somehow it wasn't very easy for me to find information about how to check out the source from CVS, but I found it in the chuck-dev mailing list archive, eventually. Maybe it's time I subscribe there, too. The problem is that chuck_instr.h has this: #define uint unsigned long and sys/types.h has: #ifndef _POSIX_C_SOURCE ... typedef unsigned int uint; /* Sys V compatibility */ #endif which results in a: typedef unsigned int unsigned long; Fixing this is not the only hurdle, later on you'll see things like: /var/tmp//ccAPkhiP.s:20471:no such 386 instruction: `fctiw' /var/tmp//ccAPkhiP.s:20472:no such 386 instruction: `stfd' which is caused by inline assembly for the wrong architecure getting picked up from util_sndfile.h (looks like OS X does have lrint() and lrintf() so there should be no need for asm at all). An Intel Mac shouldn't be necessary to debug these kinds of issues. All you need is recent developer tools with universal libraries and you'll be able to specify "-arch i386" in compiler and linker flags to produce Intel binaries on a PPC machine. -Jukka

An Intel Mac shouldn't be necessary to debug these kinds of issues. All you need is recent developer tools with universal libraries and you'll be able to specify "-arch i386" in compiler and linker flags to produce Intel binaries on a PPC machine.
Are you suggesting to build the (universal)binary on a ppc and use that instead of compiling it on the intel? I kind of dislike it ...

I forgot to thank you for finding where the error comes from. eduard
I am seeing this, too. First, a disclaimer. I've barely gotten into using ChucK and hadn't looked at source until I heard about this problem. Somehow it wasn't very easy for me to find information about how to check out the source from CVS, but I found it in the chuck-dev mailing list archive, eventually. Maybe it's time I subscribe there, too.
The problem is that chuck_instr.h has this:
#define uint unsigned long
and sys/types.h has:
#ifndef _POSIX_C_SOURCE ... typedef unsigned int uint; /* Sys V compatibility */ #endif
which results in a:
typedef unsigned int unsigned long;
Fixing this is not the only hurdle, later on you'll see things like:
/var/tmp//ccAPkhiP.s:20471:no such 386 instruction: `fctiw' /var/tmp//ccAPkhiP.s:20472:no such 386 instruction: `stfd'
which is caused by inline assembly for the wrong architecure getting picked up from util_sndfile.h (looks like OS X does have lrint() and lrintf() so there should be no need for asm at all).
An Intel Mac shouldn't be necessary to debug these kinds of issues. All you need is recent developer tools with universal libraries and you'll be able to specify "-arch i386" in compiler and linker flags to produce Intel binaries on a PPC machine.
-Jukka _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Eduard/Jukka, Could you edit line 7 your makefile like to look like this: FLAGS=-D__MACOSX_CORE__ -D__LITTLE_ENDIAN__ -c and try recompiling? On our PPC systems, __LITTLE_ENDIAN__ is predefined when cross- compiling for x86, and I had thought that that would be the case on x86 systems also. However, judging by the nature of your build errors, it seems that this preprocessor macro might not be present. spencer On Sep 11, 2006, at 7:20 PM, Jukka Akkanen wrote:
On Sep 11, 2006, at 5:06 PM, Ge Wang wrote:
Hi Eduard!
When building chuck from cvs in macintel got the following:
gcc -D__MACOSX_CORE__ -O3 -c chuck_instr.cpp /usr/include/sys/types.h:86: error: declaration does not declare anything
This is quite strange. We don't have a macintel around, so we'll try to debug remotely. I checked in a slight change to the offending file, please update and try compiling again?
Also: 1. what gcc version on macintel? 2. does the release 1.2.0.6 compile or do you get the same error?
Anyone else encounter the same problem?
I am seeing this, too. First, a disclaimer. I've barely gotten into using ChucK and hadn't looked at source until I heard about this problem. Somehow it wasn't very easy for me to find information about how to check out the source from CVS, but I found it in the chuck-dev mailing list archive, eventually. Maybe it's time I subscribe there, too.
The problem is that chuck_instr.h has this:
#define uint unsigned long
and sys/types.h has:
#ifndef _POSIX_C_SOURCE ... typedef unsigned int uint; /* Sys V compatibility */ #endif
which results in a:
typedef unsigned int unsigned long;
Fixing this is not the only hurdle, later on you'll see things like:
/var/tmp//ccAPkhiP.s:20471:no such 386 instruction: `fctiw' /var/tmp//ccAPkhiP.s:20472:no such 386 instruction: `stfd'
which is caused by inline assembly for the wrong architecure getting picked up from util_sndfile.h (looks like OS X does have lrint() and lrintf() so there should be no need for asm at all).
An Intel Mac shouldn't be necessary to debug these kinds of issues. All you need is recent developer tools with universal libraries and you'll be able to specify "-arch i386" in compiler and linker flags to produce Intel binaries on a PPC machine.
-Jukka _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Hi David, On Sat, 9 Sep 2006, David Powers wrote:
If I was going to request three additional "bread and butter" UGen's, I'd ask for 1. Compressor 2. Limiter 3. TubeOverdrive (ie. analog simulation)
I just built a combination compressor/limiter/gate/expander for chuck and posted it to chuck-dev, along with instructions for installing it. https://lists.cs.princeton.edu/pipermail/chuck-dev/2006-September/000182.htm... If you have time, please try it out and see if it works for you!
I'd also love to see a port of the destroyFX stuff, I think their source code is available: http://destroyfx.smartelectronix.com/
It seems like a cool way to do this would be implementing VST support. Then chuck could talk to lots of plugins. Not sure how difficult it us, but the "standardness" of it might make it worth it. cheers, Graham
On 9/9/06, Ge Wang
wrote: Greetings fellow ChucKists,
Here is a (not so) quick summary/warning about upcoming changes in chuck-1.2.0.7, to be released probably next week.
what it don't got: - garbage collection is still on a holding pattern and will not be in 1.2.0.7 - the long-overdue string operations, unfortunately, insist on waiting for garbage collection, and also will not in 1.2.0.7 - file i/o api's have been implemented (thanks to Martin Robinson), will be included soon but not in 1.2.0.7 Sorry about that.
Now that we've apologized about what's not in the release, it's time to apologize about what is. Due to recent discussions on this list, two sets of changes and additions have been made. We want to preview them here to get feedback before setting them in concrete.
API deprecations. Our discussion more or less determined that it's best to unify the naming scheming now before things get further out of hand, particularly for UGen names and such. So the current solution deprecates the object names in question and provides more consistent naming. By default, when a deprecated name, such as 'sinosc', is encountered, a warning will be issued, such as 'line(1): deprecated: 'sinosc' --> use: 'SinOsc''. The behavior should be otherwise unchanged. In other words the program should still work as before. We've also added a --deprecate flag that allows you to stop, warn, or ignore upon encountering a deprecated item. The default is 'warn'.
Here are the objects deprecated so far, and their replacements:
- (api) deprecated --> new classes -------------------------- sinosc --> SinOsc triosc --> TriOsc sqrosc --> SqrOsc sawosc --> SawOsc pulseosc --> PulseOsc phasor --> Phasor osc --> Osc noise --> Noise cnoise --> CNoise impulse --> Impulse step --> Step halfrect --> HalfRect fullrect --> FullRect gain --> Gain zerox --> ZeroX delayp --> DelayP sndbuf --> SndBuf pan2 --> Pan2 mix2 --> Mix2 onepole --> OnePole onezero --> OneZero polezero --> PoleZero twopole --> TwoPole twozero --> TwoZero biquad --> BiQuad
std --> Std math --> Math machine --> Machine
A few more UGen's. From another discussion on list, also by popular demand, it seems convenient to have out-of-the-box filters, in addition to general 1st and 2nd order filters (OnePole/Zero, BiQuad, etc.). We've examined and plundered from Csound, SC, and PD source code, and chuckified a few UGen's. We are going to do this in installments, adding various UGens every release. In 1.2.0.7, They include:
LPF : lowpass filter (2nd order butterworth) (also with cutoff resonance control) HPF : highpass filter (2nd order butterworth) (also with cutoff resonance control) BPF : bandpass filter (2nd order butterworth) BRF : bandreject filter (2nd order butterworth) ResonZ : resonant filter (BiQuad with equal-gain zeros) FilterBasic : base class to above filters
Of course, all of these can be designed and implemented using existing filters, but these provide direct access to cutoff and Q out-of-the-box and behave in a familiar um Butterworthy way. (More are on the way)
We'd appreciate your feedback on these. For example: 1. api changes are in general, not reasons for group celebration. what can be done to further smooth the transition? 2. new naming optimal? 3. anything else
Thanks!
Best, chuck team
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

On 9/10/06, Graham Coleman
Then chuck could talk to lots of plugins.
Not sure how difficult it us, but the "standardness" of it might make it worth it.
That would be nice, if asking for trouble; I think the VST standard isn't as standardised as one would like standards to be. For one thing we would need a way of getting a VST to report on it's parameters. This would also break the cross-platform nature of ChucK code. I imagine there would also be questions about some malfunction with plugin X where X costs 500 bucks and would be unavailable to the developers... The destroyFX stuff by itself makes little sense to me to port; many of those things could also be done with some tactfull controll of SndBuf (getting in the new habit there...). If we'dlike to get yet closer the first step IMHO should be a record mode for the SndBuf as a alternative for loading audio files? With a MIDI loopback driver and a straditional VST/AU/LADSPA/My_format host much of the same could be acomplished. Just my thoughts... Kas.

On 9/10/06, Kassen
That would be nice, if asking for trouble; I think the VST standard isn't as standardised as one would like standards to be. For one thing we would need a way of getting a VST to report on it's parameters. This would also break the cross-platform nature of ChucK code. I imagine there would also be questions about some malfunction with plugin X where X costs 500 bucks and would be unavailable to the developers...
....
With a MIDI loopback driver and a straditional VST/AU/LADSPA/My_format host much of the same could be acomplished.
Just my thoughts...
Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hi Kas, Two thoughts: 1. I'm interested in sending ChucK's audio output into VST's, so MIDI would not be a solution. MIDI would only work if ChucK wasn't generating any audio, but what I want to do is be able to process some of the things that I'm already generating in ChucK. 2. Relying on MIDI means that one loses a great deal of resolution as far as parameters go, being stuck with 0-127. Furthermore, not every host makes it easy to address a particular parameter of a plugin through MIDI. I guess, a good solution would be if ChucK could be extended with a "Plugin" UGen, that would support both LAPSDA and VST (and maybe the Mac format too), thereby allowing it to be crossplatform. Of course, I have no idea how difficult this sort of thing is. It's true, as far as the DestroyFX stuff, someone could probably build similar things using the buffer UGen. Though to get that functionality, I guess we need to create user defined UGen's?! ~David

I guess, a good solution would be if ChucK could be extended with a "Plugin" UGen, that would support both LAPSDA and VST (and maybe the Mac format too), thereby allowing it to be crossplatform. Of course, I have no idea how difficult this sort of thing is.
you can proably already use Chuck in a VST host, via the MAx/MSP Chuck~ and its VST patch-wrapper (or rewire~). whats so wrong with JACK again? :)

On 9/11/06, carmen <_@whats-your.name> wrote:
whats so wrong with JACK again? :)
It's not available for Windows where somebody decided we needed rewire instead which has all sorts of issues. I don't think it's too friendly toward open source either. Maybe we should just put a mail client and a browser in the Audicle, transform it into a OS and be done with all those pesky differences and "standards". ;¬) Kas.

On Mon, 11 Sep 2006, carmen wrote:
you can proably already use Chuck in a VST host, via the MAx/MSP Chuck~ and its VST patch-wrapper (or rewire~).
Yes -- I have built a few chuck~ instruments (and used 'em!) with pluggo, and audio i/o and MIDI i/o work fine and dandy. I guess you can bundle the run-time VST wrapper if you want to distribute the plugins. rewire also works well with chuck~. brad http://music.columbia.edu/~brad

Not everyone has a Mac ... Now if only I could run chuck in Pure Data,
on WinXP, I'd be quite happy.
~David
On 9/11/06, Bradford Garton
On Mon, 11 Sep 2006, carmen wrote:
you can proably already use Chuck in a VST host, via the MAx/MSP Chuck~ and its VST patch-wrapper (or rewire~).
Yes -- I have built a few chuck~ instruments (and used 'em!) with pluggo, and audio i/o and MIDI i/o work fine and dandy. I guess you can bundle the run-time VST wrapper if you want to distribute the plugins.
rewire also works well with chuck~.
brad http://music.columbia.edu/~brad _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

It shouldn't be too difficult to get chuck~ running on WinXP, but I don't have time to do it now. Maybe over the semester intersession... brad http://music.columbia.edu/~brad On Mon, 11 Sep 2006, David Powers wrote:
Not everyone has a Mac ... Now if only I could run chuck in Pure Data, on WinXP, I'd be quite happy.
~David
On 9/11/06, Bradford Garton
wrote: On Mon, 11 Sep 2006, carmen wrote:
you can proably already use Chuck in a VST host, via the MAx/MSP Chuck~ and its VST patch-wrapper (or rewire~).
Yes -- I have built a few chuck~ instruments (and used 'em!) with pluggo, and audio i/o and MIDI i/o work fine and dandy. I guess you can bundle the run-time VST wrapper if you want to distribute the plugins.
rewire also works well with chuck~.
brad http://music.columbia.edu/~brad _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

On 9/11/06, David Powers
1. I'm interested in sending ChucK's audio output into VST's, so MIDI would not be a solution. MIDI would only work if ChucK wasn't generating any audio, but what I want to do is be able to process some of the things that I'm already generating in ChucK.
This is completely valid. I was still in my "using ChucK to sequence" mode and thinking of synths, not effects. I simply overlooked this and now feel silly. 2. Relying on MIDI means that one loses a great deal of resolution as
far as parameters go, being stuck with 0-127. Furthermore, not every host makes it easy to address a particular parameter of a plugin through MIDI.
True, but it's my opinion that hosts should feature solid support for external controlers. I guess, a good solution would be if ChucK could be extended with a
"Plugin" UGen, that would support both LAPSDA and VST (and maybe the Mac format too), thereby allowing it to be crossplatform. Of course, I have no idea how difficult this sort of thing is.
It would certainly be noble; I'm sure this would be extremely popular but I suspect that if it were easy to make a host that ran on all three OS's and suported all those types of plugins it would already have been done. It's true, as far as the DestroyFX stuff, someone could probably build
similar things using the buffer UGen. Though to get that functionality, I guess we need to create user defined UGen's?!
For that exact functionality you'd be bussy for quite a while but the general gist of those and similar plugins isn't that hard to get with some tactfull SndBuf manipulation. You just periodically set the buffer position to some known value and the world is you oister for IDM/drill&bass style stuttering. I suppose you could get yet closer by using one of the delays but I didn't quite get into those yet. Personally I think it's a bit of a shame that new plugins in that sort of style have such a big influence on the IDM world. Plugin support would be nice in general but I think that building your own micro-looper/buffer-abuse tool is far more interesting then the quest for the latest greatest plugin. No personal attack intended, of cource; Destroyfx is great fun as well. It's not that I realy disagree, I just think advantages and hardships need to be considered. "this plugin on that host" style discussions are quite common on fora like the Ableton one which made me suspect this feature would lead to a whole lot of extra questions. If it were all up to me I'd like real OSC support in the major hosts and something like Jack for Windows. That should take care of the whole thing and on some days I wonder why those things aren't here already. Kas.

2. Relying on MIDI means that one loses a great deal of resolution as
far as parameters go, being stuck with 0-127.
that's not true.. you can combine MSB and LSB frames, for 14 bit resolution. in theory you could do more but you'd be deviating from existing implementations.
Furthermore, not every
host makes it easy to address a particular parameter of a plugin through MIDI.
sounds like a host issue, or a plugin issue, or a plugin spec issue. the host i use allows to address any plugin parameter with OSC floats, and query for addressable parameters.. Chuck supports OSC doesnt it?

sounds like a host issue, or a plugin issue, or a plugin spec issue. the host i use allows to address any plugin parameter with OSC floats, and query for addressable parameters.. Chuck supports OSC doesnt it?
Absololutely! This is our preferred means for passing control parameters around. PRC

On 9/11/06, Kassen
For that exact functionality you'd be bussy for quite a while but the general gist of those and similar plugins isn't that hard to get with some tactfull SndBuf manipulation. You just periodically set the buffer position to some known value and the world is you oister for IDM/drill&bass style stuttering. I suppose you could get yet closer by using one of the delays but I didn't quite get into those yet.
Playing randomly from the buffer is easy enough, but I think there are some other things going on in the plugins I like most. However, I'm sure as ChucK develops it won't be so hard to do these things natively in ChucK. Much more important are the bread and butter tools, like compression and the like. Having the oscillators and filters is a good start.
If it were all up to me I'd like real OSC support in the major hosts and something like Jack for Windows. That should take care of the whole thing and on some days I wonder why those things aren't here already.
Kas.
I agree 100% - Jack for Windows would solve the problem nicely. As would OSC support in the major hosts. Plogue Bidule is a decent alternative I guess, with OSC support and plugin hosting, though it tends to be somewhat CPU hungry.

Hi Chuck team, I've just checked the Feature Request list on the Wiki and couldn't find anything related to Fourier analysis... are there plans to include it at some point? thanks, eduard

Hi!
I've just checked the Feature Request list on the Wiki and couldn't find anything related to Fourier analysis... are there plans to include it at some point?
FFT and friends are most assuredly on the list. The feature request page hasn't been organized in a while, I hope to sort it at some point. In fact, we are looking at providing audio analysis framework from within chuck. George Tzanetakis, author of MARSYAS, and us chuck folks have been brainstorming about this very thing. We will definitely keep you posted. Best, Ge!

I've just checked the Feature Request list on the Wiki and couldn't find anything related to Fourier analysis... are there plans to include it at some point?
FFT and friends are most assuredly on the list. The feature request page hasn't been organized in a while, I hope to sort it at some point.
How will frames flow through a chuck wire, with respect to time?
In fact, we are looking at providing audio analysis framework from within chuck. George Tzanetakis, author of MARSYAS, and us chuck folks have been brainstorming about this very thing. We will definitely keep you posted.
This is exciting news. Graham

How will frames flow through a chuck wire, with respect to time?
From picking the Brain of Mr. Tzanetakis and combining ideas with the existing ChucK time framework: The idea is to associate arbitrary meta-data with arbitrary samples in the chuck wire, including FFT frames and feature vectors as the program is specified. There would also probably be an extra 'wire' (a new sink like dac or blackhole, except it's for the timed meta-data). For example, to set up a STFT of 128 fft size, with 64 hop size, you could hook up a FFT unit which accumulates the past 128 samples, and every 64::samp take the FFT, and put the result frame on the meta-data stream, associated with the current time/sample. This stream could then flow through other analysis units that can query and take what's on the stream and add or modify the stream. The analysis units could at the same time serve as regular UGen's if you connect them to a dac driven UGen chain, making both analysis and synthesis cooperative and synchronized. Also, this, like the synthesis system, is demand driven, and should scale without additional overhead. This may sound like we know what we're doing, which is not quite the case until we can identify hurdles and work up a good implementation plan or something. This is similar to how things flow in MARSYAS 2. We've started plotting and designing for this in ChucK, though it's unclear when a prototype would be ready to try. Best, Ge!

Greetings fellow ChucKists,
Yo!
Here is a (not so) quick summary/warning about upcoming changes in chuck-1.2.0.7, to be released probably next week.
- file i/o api's have been implemented (thanks to Martin Robinson), will be included soon but not in 1.2.0.7 Sorry about that.
Go Martin!
API deprecations. Our discussion more or less determined that it's best to unify the naming scheming now before things get further out of hand, particularly for UGen names and such. So the current solution deprecates the object names in question and provides more consistent naming. By default, when a deprecated name, such as 'sinosc', is encountered, a warning will be issued, such as 'line(1): deprecated: 'sinosc' --> use: 'SinOsc''. The behavior should be otherwise unchanged. In other words the program should still work as before. We've also added a --deprecate flag that allows you to stop, warn, or ignore upon encountering a deprecated item. The default is 'warn'.
This sounds like a pretty reasonable solution. So, for the next few releases, someone should be able to --deprecate:ignore to run their old code without any change in behavior.
A few more UGen's. From another discussion on list, also by popular demand, it seems convenient to have out-of-the-box filters, in addition to general 1st and 2nd order filters (OnePole/Zero, BiQuad, etc.). We've examined and plundered from Csound, SC, and PD source code, and chuckified a few UGen's. We are going to do this in installments, adding various UGens every release. In 1.2.0.7, They include:
Awesome!
We'd appreciate your feedback on these. For example: 1. api changes are in general, not reasons for group celebration. what can be done to further smooth the transition? 2. new naming optimal? 3. anything else
It's hard to tell what's optimal, and people dislike change in general, but I think deprecation is a good way to deal with it. Graham

Hi all. I keep meaning to post to this list about the under-exploited feature that all unit generators have, in that you can cause their inputs to multiply rather than add. As an example, here's a simple power envelope follower that doesn't require sample-level chuck intervention. A gain UG is used to square the incoming A/D signal (try it on your built-in mic), then a OnePole UG is used as a "leaky integrator" to keep a running estimate of the signal power. The main loop wakes up each 100 ms and checks the power, and prints out a message if it's over a certain level. You might need to change the threshold, but you get the idea. // SIMPLE ENVELOPE FOLLOWER, by P. Cook adc => gain g => OnePole p => blackhole; adc => g; 3 => g.op; 0.9999 => p.pole; while (1) { 0.1 :: second => now; // <<< p.last() >>>; if (p.last() > 0.2) <<< "BANG!!" >>>; }
participants (11)
-
Bradford Garton
-
carmen
-
David Powers
-
eduard aylon
-
Ge Wang
-
Graham Coleman
-
jesus gollonet
-
Jukka Akkanen
-
Kassen
-
Perry R Cook
-
Spencer Salazar