Dear all, chuck-1.2.1.2 (dracula) is available: http://chuck.cs.princeton.edu/ This release introduces dynamic auto-growing arrays, various fixes, enhancements, and likely new and better bugs/features (see below for a full list). Rebecca and I have added additional UAnae (unit analyzers, see http://chuck.cs.princeton.edu/uana/) in preparation for an all-new upcoming toolkit (following in the footsteps of S.M.E.L.T., see http://smelt.cs.princeton.edu/), which Rebecca will announce soon! A new miniAudicle is on the way from Spencer, as well as an updated audicle version. As always, let us know if you encounter unexpected fishiness (and expected fishiness as well). Many many thanks to Kassen, Kijjaz, Eduard, folks on the electro-music chuck forum, chuck-users, PLOrk, SLOrk, students and staff at CCRMA and Princeton, Fernando Lopez-Lezcano, Carr Wilkerson, and rest of the chuck community for helping to make this release happen!! Thanks and Happy ChucKing, UpChucKing! Best, chuck team CHANGES --- 1.2.1.2 - (added) dynamic, resizable arrays .size( int ) resizes array; .size() returns current size() << operator appends new elements into array .popBack() pops the last element of the array, reducing size by 1 .clear() zero's out elements of the array (see examples/array/ array_dyanmic.ck array_resize.ck) - (added) new UAna: FeatureCollector turns UAna input into a single feature vector, upon .upchuck() new UAna: Flip turns audio samples into frames in the UAna domain new UAna: pilF turns UAna frames into audio samples, via overlap add new UAna: AutoCorr computes the autocorrelation of UAna input new UAna: XCorr computes the cross correlation of the first two UAna input - (added) UGen.isConnectedTo( Ugen ) // is connected to another ugen? - (added) UAna.isUpConnectedTo( UAna ) // is connected to another uana via =^? - (added) int Shred.done() // is the shred done? int Shred.running() // is the shred running? - (added) int Math.ensurePow2( int ) - (added) Math.INFINITY, Math.FLOAT_MAX, Math.FLOAT_MIN_MAG, Math.INT_MAX - (added) TriOsc.width(), PulseOsc.width(), SawOsc.width(), SqrOsc.width() - (added) Std.system(string) is now disabled by default, to enable: specify the --caution-to-the-wind command line flag, for example: %> chuck --caution-to-the-wind --loop - (removed) SqrOsc.width( float ), width is always .5 - (fixed) it's now (again) possible to multiply connect two UGen's - (fixed) OS X only: sudden-motion-sensor HID no longer introduces audio dropouts below peak CPU usage due to added centralized polling; added static Hid.globalPollRate( dur ) to control the central SMS polling's rate - (fixed) Windows only: implementation of array via STL vector::reserve() has been replaced with a more compatible approach (see chuck_oo.cpp) - (fixed) dac amplitude no longer halved! NOTE: this increases the gain from before by a factor of 2, or roughly 6 dB!! BEWARE!! - (fixed) corrected order of shred/ugen dealloc in VM destructor, preventing a potential crash during shutdown - (fixed) UAna can now upchuck() at now==0 - (fixed) STK Chorus UGen now has reasonable defaults .max( dur, float ) for initializing to delay/depth limits .baseDelay( dur ) sets current base delay - (fixed) dur +=> now no longer crashes - (fixed) ADSR now returns attackTime, decayTime, and releaseTime that corresponds to the duration-based setting functions (internally multiplied by SR) (thanks Eduard) - (fixed) STK Mandolin no longer plays without explicit noteOn - (fixed) unsporked Shred instances now given id == 0 (thanks Kassen) - (fixed) typos in ugen_xxx.cpp and chuck-specific rtaudio.cpp (/moudi)
ons 2008-07-16 klockan 04:42 -0700 skrev Ge Wang:
Dear all,
chuck-1.2.1.2 (dracula) is available:
http://chuck.cs.princeton.edu/
This release introduces dynamic auto-growing arrays, various fixes, enhancements, and likely new and better bugs/features (see below for a full list). Rebecca and I have added additional UAnae (unit analyzers, see http://chuck.cs.princeton.edu/uana/) in preparation for an all-new upcoming toolkit (following in the footsteps of S.M.E.L.T., see http://smelt.cs.princeton.edu/), which Rebecca will announce soon! A new miniAudicle is on the way from Spencer, as well as an updated audicle version. As always, let us know if you encounter unexpected fishiness (and expected fishiness as well).
Many many thanks to Kassen, Kijjaz, Eduard, folks on the electro-music chuck forum, chuck-users, PLOrk, SLOrk, students and staff at CCRMA and Princeton, Fernando Lopez-Lezcano, Carr Wilkerson, and rest of the chuck community for helping to make this release happen!!
Thanks and Happy ChucKing, UpChucKing!
Best, chuck team
Great news!
CHANGES --- 1.2.1.2 - (added) dynamic, resizable arrays .size( int ) resizes array; .size() returns current size() << operator appends new elements into array
Is this really right? are we doing right-to-left assignment now?
.popBack() pops the last element of the array, reducing size by 1 .clear() zero's out elements of the array (see examples/array/ array_dyanmic.ck
cheers, Gasten
Martin Ahnelöv ;
- (added) dynamic, resizable arrays .size( int ) resizes array; .size() returns current size() << operator appends new elements into array
Is this really right? are we doing right-to-left assignment now?
I think the idea is that a value is appended, which means (reading left to right) it ends up on the right end of the array so it's easiest to visualise it as "entering from the right". I could also imagine a ">>" operator that would enter values at the beginning of the array, moving the rest one step to the right. I like it for appending single numbers, so far. This seems in tune with the general "like you read it" philosophy of ChucK; 32 => Std.motof => my_osc.freq; is more readable to me then the equivalent my_osc.freq( Std.mtof( 32) ); However, now re run into the situation where if we'd like to append a float we need to do this; my_pitches_array << Std.mtof( 32); Instead of sending the number into mtof like; //warning; non-valid!!! my_pitches_array << 32 => Std.mtof; ...which ChucK interprets as a attempt so send a array of floats into mtof, which predictably fails (and I'm not sure I like it for functions that do take arrays as their argument because the poor number looks like it's being quartered but that's no great issue as such a operation would be better with two lines anyway). In practice this means that if we have some chain of functions that calculates a number which we'd like to append to a array (seems like a likely scenario to me) we need to do this; my_pitches_array << ( 32 => Std.mtof); ...that one does work but I'd say it won't win any beauty awards in the "operate like it looks" department since it looks a bit confusing to me. In that case I think I'd prefer something like; //warning; concept, doesn't actually run 32 => Std.mtof => my_pitches_array.apnd; I'd say that's not as intuitively "left to right" as the current situation for appending a single number but much better then the thing we now get if that number is the result of a chain of calculations yet doesn't have a name. As I see it so far this new feature encourages either naming variables or code that looks weird to me right now. I have no strong opinion on any of this yet, I'll have to see how it works out in practice but these are some of my thoughts on it so far. I do think "<<" is quite ChucKian as a concept but I suspect it will lead to less-then-ChucKian results in non-trivial contexts. Yours, Kas.
Kas. wrote: In that case I think I'd prefer something like; //warning; concept, doesn't actually run 32 => Std.mtof => my_pitches_array.apnd; I'd say that's not as intuitively "left to right" as the current situation for appending a single number but much better then the thing we now get if that number is the result of a chain of calculations yet doesn't have a name. ... Why not something like: 32 => Std.mtof => my_pitches_array[]; I think the bracket notation is very standard (i.e. people are used to it from many languages), and it seems to be less confusing and fits the left-to-right reading order. Just my one cent! -- Rich ----- Original Message ----- From: Kassen To: ChucK Central Mailing List Sent: Tuesday, July 22, 2008 11:41 PM Subject: Re: [chuck] 1.2.1.2 (dracula) unleashed Martin Ahnelöv ; > - (added) dynamic, resizable arrays > .size( int ) resizes array; .size() returns current size() > << operator appends new elements into array Is this really right? are we doing right-to-left assignment now? I think the idea is that a value is appended, which means (reading left to right) it ends up on the right end of the array so it's easiest to visualise it as "entering from the right". I could also imagine a ">>" operator that would enter values at the beginning of the array, moving the rest one step to the right. I like it for appending single numbers, so far. This seems in tune with the general "like you read it" philosophy of ChucK; 32 => Std.motof => my_osc.freq; is more readable to me then the equivalent my_osc.freq( Std.mtof( 32) ); However, now re run into the situation where if we'd like to append a float we need to do this; my_pitches_array << Std.mtof( 32); Instead of sending the number into mtof like; //warning; non-valid!!! my_pitches_array << 32 => Std.mtof; ...which ChucK interprets as a attempt so send a array of floats into mtof, which predictably fails (and I'm not sure I like it for functions that do take arrays as their argument because the poor number looks like it's being quartered but that's no great issue as such a operation would be better with two lines anyway). In practice this means that if we have some chain of functions that calculates a number which we'd like to append to a array (seems like a likely scenario to me) we need to do this; my_pitches_array << ( 32 => Std.mtof); ...that one does work but I'd say it won't win any beauty awards in the "operate like it looks" department since it looks a bit confusing to me. In that case I think I'd prefer something like; //warning; concept, doesn't actually run 32 => Std.mtof => my_pitches_array.apnd; I'd say that's not as intuitively "left to right" as the current situation for appending a single number but much better then the thing we now get if that number is the result of a chain of calculations yet doesn't have a name. As I see it so far this new feature encourages either naming variables or code that looks weird to me right now. I have no strong opinion on any of this yet, I'll have to see how it works out in practice but these are some of my thoughts on it so far. I do think "<<" is quite ChucKian as a concept but I suspect it will lead to less-then-ChucKian results in non-trivial contexts. Yours, Kas. ------------------------------------------------------------------------------ _______________________________________________ chuck mailing list chuck@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck
participants (4)
-
Ge Wang -
Kassen -
Martin Ahnelöv -
Rich Caloggero