[chuck-users] heads up for 1.2.0.7

[David Powers]

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 <gewang at 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 at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>