[chuck-users] heads up for 18.104.22.168
gc at gehennom.net
Sun Sep 10 17:05:30 EDT 2006
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.
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:
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.
> On 9/9/06, Ge Wang <gewang at cs.princeton.edu> wrote:
> > Greetings fellow ChucKists,
> > Here is a (not so) quick summary/warning about upcoming changes in
> > chuck-22.214.171.124, to be released probably next week.
> > what it don't got:
> > - garbage collection is still on a holding pattern and will not be in
> > 126.96.36.199
> > - the long-overdue string operations, unfortunately, insist on waiting
> > for garbage collection, and also will not in 188.8.131.52
> > - file i/o api's have been implemented (thanks to Martin Robinson),
> > will be included soon but not in 184.108.40.206
> > 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 220.127.116.11, 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 at lists.cs.princeton.edu
> > https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
More information about the chuck-users