This may be of interest to some on the chuck-users mailing list. Apologies in advance for list cross-posting; we're trying to spread the word far and wide (and please pass this along to other individuals or lists you think may be interested). Thanks! brad http://music.columbia.edu/~brad -------------- Columbia University Music Department Composition and Theory Assistant Professor Opening The Department of Music at Columbia University announces a full-time non-tenured position in Music Composition and Theory, at the rank of Assistant Professor, to begin 1 July 2007. The successful candidate will be expected to carry out creative work, teach music composition and theory at undergraduate and graduate levels, and potentially teach in other areas of intellectual interest. He or she will also be expected to teach in the undergraduate Core Curriculum and participate actively in the development of the Department's programs. We seek candidates who can contribute through their composing, research, teaching, and service to the diversity and excellence of the academic community at Columbia. An appropriate doctorate or the equivalent is required for this position. Significant work as a composer and/or music theorist is the most important qualification. We welcome applicants with a wide range of aesthetic and technical orientations. A candidate's involvement in areas that would expand the scope of compositional and theoretical research at Columbia will be viewed as an advantage. All continuing appointments at Columbia begin with a one-year contract, with renewal anticipated. Columbia University is an Affirmative Action/Equal Opportunity Employer. Women and minorities are encouraged to apply. Send a letter of application, curriculum vitae, and three letters of recommendation to: Brad Garton Chair, Composition Theory Search Committee Columbia University Department of Music 621 Dodge Hall, MC1813 2960 Broadway New York NY 10027 USA Review of applications will begin January 15, 2007.

David Michael wrote:

I look forward to the addition of <snip> array.size()

Did you look at array.cap()? -- peace, love & harmony Atte http://www.atte.dk | quintet: http://www.anagrammer.dk | compositions: http://www.atte.dk/compositions

On 12/8/06, David Michael wrote:

Yep, but array.cap() gives me the capacity of the array, not the size. Maybe a "size" method this is only a feature for growable/dynamic arrays (which would also be dreamy - aahhh push and pop). In fact, it would be nice if a ChucK array was not a fixed-length data structure.

Currently, if I would like to find out how many members of an array are currently occupied (for imposing limits on member and such), I must keep an int variable as I add members to the array. It is really only in this way that I have found to loop over only the members of the array that are actually filled with something. It is always possible to write a wrapper class to abstract some of this functionality...

Have I missed something in the way that the ChucK array has been implemented?

I think you have to do the same thing when coding in C ... the answer is usually to write some kind of "SuperArray" class that has extra methods (functions) and properties. To me you'd want, of course, a length property, and for methods stuff like, "sort", "reverse", "shuffle", "removeDuplicates", "find", etc... All these functions are especially useful if you want to store stuff like note data and cells in arrays, and manipulate them. In fact, I was trying to work on this a long time ago, but when I posted something about it to the list, I got ignored at that time. So I sort of gave up and moved on to other software. ~David

On 12/8/06, David Michael wrote:

On 12/8/06, David Powers wrote:

...

In fact, I was trying to work on this a long time ago, but when I posted something about it to the list, I got ignored at that time. So I sort of gave up and moved on to other software.

Was this the post on HyperArray? I liked that class alot, it showed me how to work around the deficiencies of array.

Now that I have learned ChucK, I feel a bit more comfortable trying to implement it. But even HyperArray needs to have a set number of array items... and I have to make sure to include the class in a running instance of ChucK or either explicitly write the class in the file I want to use it in.... not exactly the most portable thing in the world, especially considering that there is not really another way to include files in classes, except on the command line.

The ChucK array object in general neednt follow the array conventions in C, but it does. Having said all that, I realize that ChucK is under development and a phD thesis. I still would love to see more powerful native arrays (like Ruby's or JavaScript's, which I realize are probably really linked lists).

~other David

Hello, yes, that was it. I didn't know anybody paid attention, maybe I would have kept at it. This post actually gives me a little incentive to return to ChucK and pick up where I left off. And I do agree with all of the above. Haven't used Ruby, but I've used lists in Python, it's amazing how fast you can perform various manipulations. I'm not a programmer, so my reference to C just mentioned it, because I took a C/C++ class once, and I have some vague familiarity. But I'm becoming more of a programmer all the time (Unfortunately, my main programming work currently, is writing portfolio pieces like arcade games in Flash ActionScript 2.0, which maybe doesn't qualify me as any kind of programmer at all, but at least it's got fairly good OOP and I'm having to write a lot of classes and think through their relationships.) But, as far as the missing array functionality, I think once they get the object-oriented/class stuff sorted out, that would also solve the problem. It just needs to be easier to extend chuck and include classes. It would be especially great if you could automatically tell chuck to include any classes within some specified folder, by default. So all your basic extended functionality just shows up in any chuck programs you run. ~David

Hi, I didn't look through the code too carefully, but you description of dither is great. What I think may be happening here is that most audio programs don't handle floats as 16 bit numbers, but rather 32 bit. They do this exactly because of what you demonstrate here, if you turn the gain down and then back up it would sound terrible. The larger internal precision allows the data (in this case your sound) to stay in tact and not introduce errors. There is another complication. Floating point numbers aren't stored the same way that integers are, they are stored as a mantissa and exponent. This technique also combats the precision problem. What will happen is that the mantissa will stay the same and you are just twiddling the exponent bits. No loss of precision. You could definitely do this demonstration in chuck, and it is excellent, but I think we will have to hear from Ge, Spencer or Perry about exactly how much you will need to turn the gain down in order to achieve the desired effect. Wikipedia gives a pretty good rundown on floating point representation. http://en.wikipedia.org/wiki/Floating_point I hope this helps. --art On 10-Dec-06, at 6:36 AM, eduard aylon wrote:

Hello list,

This is probably not a question about chuck, but as I am trying to explain how dither works to other people by using chuck I thought I might post the question anyway. Please correct me if I am wrong... In principle dither is used in order to make quantization noise not perceivable. So, taking a 16bit audio file down by 60dB and then up again by 60dB without applying dither will cause quantization errors to be very audible. However when applying dither (both when de-amplifying and amplifying) a hiss maybe perceived but the signal should be recovered in a better way, or at least the quantization error should be less perceivable. In order to achieve this, I have implemented the following function in chuck (note that at the moment I am not interested in noise shaping techniques, but just adding "pure" white noise )

fun void change_gain_with_dither( float dB, string input_filename, string output_filename ) { 16 => int bit_reso; 1 << (bit_reso-1) => int max; .5/max => float noise_floor; // noise level at half LSB <<< "noise floor:", noise_floor >>>; Math.pow( 10., dB/20.) => float gain_factor; <<<"changing gain to file", input_filename>>>; <<<" amount in dB:", dB >>>; <<<" amount linear:", gain_factor >>>; <<<" dither:", "yes">>>; <<<" output file:" , output_filename >>>; sndbuf buf => dac; buf.read( input_filename ); impulse p => WvOut audio => blackhole; audio.aifFilename( output_filename ); now => time begin; buf.length() +=> begin; while( now < begin ) { std.rand2f(-noise_floor, noise_floor ) => float dither; (buf.last() + dither )*gain_factor => p.next; 1::samp => now; } audio.closeFile( output_filename ); }

However, this function seems to not give better results than the one below, which doesn't take dither into account:

fun void change_gain_without_dither( float dB, string input_filename, string output_filename ) { Math.pow( 10., dB/20.) => float gain_factor; <<<"changing gain to file", input_filename>>>; <<<" amount in dB:", dB >>>; <<<" amount linear:", gain_factor >>>; <<<" dither:", "no">>>; <<<" output file:" , output_filename >>>; sndbuf buf => dac; buf.read( input_filename ); impulse p => WvOut audio => blackhole; audio.aifFilename( output_filename ); now => time begin; buf.length() +=> begin; while( now < begin ) { buf.last()*gain_factor => p.next; 1::samp => now; } audio.closeFile( output_filename ); }

So from the next two options:

A) change_gain_without_dither( -60, file1, file2 ); change_gain_without_dither( 60, file2, file4 );

and

B) change_gain_with_dither( -60, file1, file3 ); change_gain_with_dither( 60, file3, file5 );

I would have expected B) giving "better" results than A), but in fact I obtain even worse results, i.e.: same quantisation error + hiss.

So, in the end, I am pretty sure that my understanding of dither might not be the correct one. Could anyone shred some light on this subject?

thanks,

eduard

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Hi all! Yet another solution: instead of dealing with floating point numbers, simulate the quantization using fixed point integers. Here is a quick-and-dirty example which casts the output of an arbitrary UGen into int, simulates quantization by throwing away extra bits, and optional adds dither (before the cast): http://soundlab.cs.princeton.edu/drop/dither.ck You can also modify the code to send arbitrary UGen's into play_with_dither() to hear quantization with and without dithering. I hope this is on the right track. Best, Ge! On Dec 10, 2006, at 6:43 PM, Kassen wrote:

Adam;

...

There is another complication. Floating point numbers aren't stored the same way that integers are, they are stored as a mantissa and exponent. This technique also combats the precision problem. What will happen is that the mantissa will stay the same and you are just twiddling the exponent bits. No loss of precision. You could definitely do this demonstration in chuck, and it is excellent, but I think we will have to hear from Ge, Spencer or Perry about exactly how much you will need to turn the gain down in order to achieve the desired effect.

Yes, I think that explains what is observed. As I understand floating point we could force (some) data degradation by amplifying the signal by some ratio that can't be expressed exactly in the exponent, forcing adjustment in the data itself. Floating point does have rounding errors but I seem to remember those tend to show up in particular when very large numbers and very small ones are confronted with eachother.

A more practical way of demonstrating dithering might be to have some generated piece and record it (in ChucK) to a wave file at a low gain in order to leave headroom in case several elements decide to be loud at the same time. This data would be written to a fixed point file (since ChucK doesn't support floating point formats yet) After this ChucK might be used again to increase the amplitude to make the loudest part close to 0db at which point dithering would be usefull? If we are after a demonstration that might count as a fairly realistic real-world scenario, I could imagine somebody wanting to publish a algorithmic piece without clipping that would be made and processed entirely in pure ChucK. Personally I tend to be in favour of real-world scenarios for demonstrations but this isn't my experiment so maybe this isn't relevant at all.

Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users