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
Date: 2006/09/10 Sun PM 05:05:30 EDT To: ChucK Users Mailing List 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.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
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users