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

Re: [chuck-users] heads up for 1.2.0.7
by q.h.r.h. 11 Sep '06

11 Sep '06

Sweet, I'm excited for the new filters. -Quinton

1 0

Re: [chuck-users] heads up for 1.2.0.7
by babiakb＠bellsouth.net 10 Sep '06

10 Sep '06

I am really excited to see some new filters in ChucK. I think the new version sounds promising and hope to try it out soon! Graham, your links are great! thanks for sharing the ugens. i didn't know ChucKdev had this sort of thing. i need to look that over too. Brian > > From: Graham Coleman <gc(a)gehennom.net> > Date: 2006/09/10 Sun PM 05:05:30 EDT > To: ChucK Users Mailing List <chuck-users(a)lists.cs.princeton.edu> > Subject: Re: [chuck-users] heads up for 1.2.0.7 > > 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.ht… > > 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 <gewang(a)cs.princeton.edu> 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(a)lists.cs.princeton.edu > > > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > > > > > _______________________________________________ > > chuck-users mailing list > > chuck-users(a)lists.cs.princeton.edu > > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users > > > _______________________________________________ > chuck-users mailing list > chuck-users(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users >

1 0

Re: [chuck-users] heads up for 1.2.0.7
by mrcarp＠comcast.net 09 Sep '06

09 Sep '06

One thing that comes to mind regarding to the new API naming is that it'd be faster to type the deprecated names rather than their new names. I also like how the all lower-case names look in the code. Matt -------------- Original message ---------------------- From: Ge Wang <gewang(a)CS.Princeton.EDU> > 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(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

1 0

Survey on Musical Instruments
by thor 08 Sep '06

08 Sep '06

Dear ChucK people. We'd be very interested in your views: [with apologies of cross posting] To all musicians (acoustic and digital instrumentalists) and composers We are doing a little survey on people's relationship with their instruments and tools. It is a comparative study of the differences between acoustic and digital instruments from the perspective of usability or ergonomics. Amongst many other things, we are interested in the experience of playing or composing for the different instruments, but also people's views on how the instrument/tool affects the musical ideas and what can be played/composed. Please help us to get an understanding of these issues by filling out the following survey: http://www.ixi-software.net/survey We will of course present our findings when processed with a research paper and online presentations. Thanks in advance. the ixi team

1 0

MAUI?
by eun.sung＠no-log.org 31 Aug '06

31 Aug '06

hi i'm trying running miniAudicle 1.3.5 on osX.4.6 as i try to launch slide01.ck, i get the following console output : [slide01.ck]:line(1): undefined type 'MAUI_Slider'... [slide01.ck]:line(1): ... in declaration ... and it gives the same with the different MAUI elements does using MAUI elements need some particular requirements? thanks

4 5

miniAudicle-0.1.3.4 failed to build on Gentoo Linux
by schwaahed 29 Aug '06

29 Aug '06

Hi, I am running Gentoo Linux. I failed to build miniAudicle-0.1.3.3, but I assumed it was the wxWidgets unicode issue. I am running wxGTK-2.6.3.2. Any clue on what I need to do to get this to build? schwaahed schwaabook miniAudicle-0.1.3.4 # make linux-jack make -f makefile.jack make[1]: Entering directory `/usr/local/music/ChucK/miniAudicle-0.1.3.4' gcc -o wxw/mAParentFrame.o -D__LINUX_JACK__ -D__LINUX__ -D__MA_WXWIDGETS__ `wx-config --cppflags` -O3 -c -DwxABI_VERSION=20600 -D__CK_SNDFILE_NATIVE__ -Ichuck/src -Iwxw -I/usr/local/music/ChucK/miniAudicle-0.1.3.4 wxw/mAParentFrame.cpp wxw/mAParentFrame.cpp: In member function `virtual bool mAApp::OnInit()': wxw/mAParentFrame.cpp:159: error: `wxCommandEventHandler' was not declared in this scope make[1]: *** [wxw/mAParentFrame.o] Error 1 make[1]: Leaving directory `/usr/local/music/ChucK/miniAudicle-0.1.3.4' make: [linux-jack] Error 2 (ignored)

4 22

syntax coloring for chuck in jedit
by jes�s gollonet 23 Aug '06

23 Aug '06

Hi all. I've just published a chuck edit mode (an xml file defining a syntax coloring scheme) for the jedit code editor. It gives different colors for ugens, methods, keywords and operators. If anyone uses jedit, you can grab the xml file and see the instructions in my blog: http://www.jesusgollonet.com/blog/?p=135 If you want to give it a try, i totally recommend it as a single all-purpose editor. It's totally extensible and I'm working on some more niceties for chuck editing (abbreviations, macros...). www.jedit.org Best! -- jesús gollonet htt://www.jesusgollonet.com

2 1

syntax coloring for chuck in jedit
by jes�s gollonet 23 Aug '06

23 Aug '06

Hi all. I've just published a chuck edit mode (an xml file defining a syntax coloring scheme) for the jedit code editor. It gives different colors for ugens, methods, keywords and operators. If anyone uses jedit, you can grab the xml file and see the instructions in my blog: http://www.jesusgollonet.com/blog/?p=135 If you want to give it a try, i totally recommend it as a single all-purpose editor. It's totally extensible and I'm working on some more niceties for chuck editing (abbreviations, macros...). www.jedit.org Best! -- jesús gollonet htt://www.jesusgollonet.com

1 0

syntax coloring for chuck in jedit
by jes�s gollonet 23 Aug '06

23 Aug '06

Hi all. I've just published a chuck edit mode (an xml file defining a syntax coloring scheme) for the jedit code editor. It gives different colors for ugens, methods, keywords and operators. If anyone uses jedit, you can grab the xml file and see the instructions in my blog: http://www.jesusgollonet.com/blog/?p=135 If you want to give it a try, i totally recommend it as a single all-purpose editor. It's totally extensible and I'm working on some more niceties for chuck editing (abbreviations, macros...). www.jedit.org Best! -- jesús gollonet htt://www.jesusgollonet.com

1 0

stk ugens
by Bradford Garton 19 Aug '06

19 Aug '06

chUcK-people -- Maybe I'm unaware of something (I'm fairly new to chuck-ing), but I try a really simple script like this: Saxofony sax; 0.5 => sax.stiffness; and I get this: [ccc.ck]:line(3): class 'Saxofony' has no member 'stiffness' ditto for a number of the other control parameters listed in the docs. Grepping through the code shows that they don't seem to exist. Or am I missing something fundamental? brad http://music.columbia.edu/~brad

2 2