[chuck-users] heads up for 1.2.0.7

[mrcarp at comcast.net]

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