SuperCollider Tutorial: 6. Iteration 

Chris Casey Simply, it's designed that way. The first argument in a 'do' function always represents the ordered content in the collection, and the second is always an integer index, starting at zero.

Eli Fieldsteel Thank you so much! :)

The curly braces delineate a function, and in combination with duplication (the ! symbol) it's a technique for creating an array of random numbers. When a function is duplicated, it is evaluated once for each item to be created in the resulting array. When the contents of the function are random, we get multiple uniquely-generated random numbers: {rrand(0,9)}!6; If the curly braces are removed, we create one random number, and then duplicate it: rrand(0,9)!6; The implications for synthesis should be obvious here - if we want a cluster of different random tones, the curly braces are necessary.

shame on me ;-)

I discuss the difference between rrand and Rand, as well as the use of curly braces, in tutorial 5, between 8:10 and 10:35.

Thanks Eli, I just checked those references out, much clearer now (and very interesting also).

Instead of Env.perc, use Env.adsr, which will sustain as long as the gate argument is positive.

+Enrico Borba No, that would run into the same problem. It is not possible to modulate the size of UGen Arrays while the Synth which contains these Arrays is running on the server. UGen Array size is fixed and determined at SynthDef load time. Solutions include either creating different SynthDefs with different iteration counts (one with 10.do, one with 20.do, etc), or eliminate the iteration within the SynthDef altogether, and instead use iteration to create multiple Synths from a non-iterative SynthDef.

I am extremely new to this so I might be babbling but wouldn't it be possible to have a argument that limits the volume of the iteration if bigger than? as in: if ( count

It's a good thought, certainly, but because SC is an audio programming language, familiar problems can't always be solved by approaches that might be applied in more traditional programming languages. By design, the server (scsynth) can't dynamically change the size of arrays in UGen functions, once these functions are built and sent from the language (sclang). One apparent consequence of this design is that numChannels arguments within buffer-playing UGens can't be modulated. So, the operation 0.dup(num) gets evaluated once, when the UGen function is built, but can't be updated with set commands while playing on scsynth. Operations like if, do, collect, etc. are similar. They're language-side methods that the server doesn't understand. There are relatively simple workarounds to this seemingly annoying design choice, e.g. create a SynthDef that plays one partial and dynamically create and remove multiple Synth instances, or create a SynthDef that plays a fixed number of partials with a literal Array argument for setting individual partial amplitudes, etc. I see users encounter problems related to this feature from time to time, and usually direct them here to start: supercollider.github.io/tutorials/If-statements-in-a-SynthDef.html From the SynthDef help file: "It is important to understand that although a single def can provide a great deal of flexibility through its arguments, etc., it is nevertheless a static entity. A def's UGen graph function (and the SC code within it) is evaluated only when the def is created. Thus statements like while, do, collect etc. will have no further effect at the time the def is used to create a Synth, and it is important to understand that a UGen graph function should not be designed in the same way as functions in the language, where multiple evaluations can yield different results. It will be evaluated once and only once."

It depends on the units of the mapped parameter and/or how I want to distribute values within the range. For example, our perception of pitch is logarithmic (octaves "sound" equally spaced and appear equally spaced on the keyboard, but have exponentially increasing frequency values). So, if we are using a UGen to generate MIDI note numbers, range typically makes sense for an equal (linear) distribution and a more "natural" distribution. But, for generating frequency values, exprange makes more sense. Consider what would happen if we used range for an LFNoise1 generating frequency values between 20 and 20,000. Approximately half the values would fall in the upper half of the range, which is only one octave (10-20k). But there are nine more octaves below! So we'd hear disproportionately more high frequencies and fewer low/mid frequencies. A similar phenomenon happens with decibels, for which range is usually appropriate, vs. normalized amplitude values, for which exprange is usually more appropriate. Try the difference for yourself and listen closely!

Iteration methods (do, collect, select, reject, etc) operate on a receiver, usually a collection (e.g. Array) and pass up to two arguments into their function. These arguments represent the current object from the collection, and the current integer index of that object, and are interpreted *in that order*. We gain access to these two values by declaring two arguments (e.g. "arg item, count") at the start of the function. We can name the arguments whatever we like (e.g. arg a, b; arg foo, bar), but the important point here is that the arguments are interpreted to have these meanings in this particular order. So, if we only declare one argument, it is interpreted as the object within the collection, and we have no access to the index within our function. If we want access to the index, we must declare two arguments, even if we don't plan on using the first one. A bigger problem is that, based on your approach, you are using "collect" in a case where it would be more appropriate to use "do". Remember that "do" returns its receiver, but "collect" returns a modified receiver, based on what happens inside the function. So, it is usually inappropriate/wrong to use the equals sign to update values within a collect function. When using collect, usually you will store the result of the collect operation in a new variable. With the approach you've chosen, you can simply replace both instances of "collect" with "do", and everything seems to work just fine. If you replace collect with do, then the receivers of do are simply counters that make sure the correct number of iterations occur. The actual value modification process occurs within the function, so technically, you could replace do's receivers with the number 12 -- which I think looks a little clearer. I still think collect is a more sensible choice, because it allows your array-creating code to be written more succinctly. Here's how I would do it: ~miSerie = Array.series(12,60).scramble; ~miDuraciones = ~miSerie.collect({arg item, count; item-59*0.5}); For extra brevity, you can also use the underscore character for the so-called "partial application syntax": ~miSerie = Array.series(12,60).scramble; ~miDuraciones = ~miSerie.collect(_-59*0.5); You also have one instance of ~miserie where you meant to type ~miSerie.

Very fast and clear answer, Thank you very much!

Just got it figured out using a task!

True, this is definitely a viable way to do additive synthesis!

It's a common way of applying a sequence of operations to a value, while overwriting the named container each time an operation is performed. In this case, we're calculating the sum of 'sig' and 'temp,' and storing the result in the 'sig' container, overwriting the old value. A simpler example of the same syntax looks like this: ( x = 4; x = x.pow(3); x = x - 7; )

This message occurs when you include tons and tons of UGens in your SynthDef. I think it means that your SynthDef is too big to stream to the server via add/send, so it creates a SynthDef file on your computer instead. You can try making your SynthDefs smaller or more efficient, or just ignore the warning. I get this message from time to time, and it doesn't interfere with my ability to create Synths from the SynthDef.

As far as I can tell, this SynthDef is working properly. If you make your three envelopes very different from each other (one very long, two very short), you should be able to hear the result. It may also become more audible if you remove the lowpass filter. You should also put a doneAction:2 on the longest envelope.

@@elifieldsteel thanks. I will consider supporting you and also try some of your applications. Keep on the good work