Hi Paul! Welcome!

Firstly I have to say wow, this looks great, loads of really neat features, well done!

Thanks! ChucK is very young and needs a lot of work. Some of that is coming in the new release next week.

I've had a quick play and its pretty easy to pick up, but I have a question. One thign I want to do is to play with 'VOSIM', basically you have a train of pulses (bell curves) that make up a cycle of audio. You vary the number of, amplitude and width of each curve to change the 'tone'.

Now I can see I can use a sine oscillator, square it and this will give me the bell curve, only problem here is that I get two 'bell curves' for the price of one cycle, which brings me neatly onto my next problem.. What I need to do is to change the amplitude and/or pitch of each 'pulse' at the zero crossing, great I can use Zerox, but, how do I then change the value?

zerox might not help you in this case, since the signal doesn't actually cross zero. there are several ways around this: 1) go at close to sample rate (3::samp => now), and keep track of the last few samples (use .last to get the last sample computed), and test for the inflection when the signal "dips". I put a quick and dirty version on the wiki: http://wiki.cs.princeton.edu/index.php/ChucK_Program_Bad_VOSIM 2) or: given the pulse width, keep this value and advance time by the same number of samp. (pw::samp => now), and that should put you at the right place both in time and the signal. You can move in this way to the end of each pulse, and modify the gain or width at this point, or set things to be silent and wait until the next series of pulse. This is probably the most robust way. 3) or: do everything by hand, and calculate the signal without sinosc. // patch impulse i => dac; // time loop while( true ) { // compute val and set the next sample (code omitted) val => i.next; // move to next sample in time 1::samp => now; } 4) surely, other ways exist. --- how to vary the amplitude - depends on how you set up the patch. example: // first osc to gain sinosc s1 => gain g => dac; // second osc sinosc s2 => g; // set multiply at g 3 => g.op; at any point, you can set g.gain to change the amplitude. you can also change s1.sfreq or s2.sfreq to change the frequency, and s1.phase and s2.phase to set the phase.

Is there a sequencer module planned?

Not natively. The idea is that it should be straightforward to implement sequencers in ChucK, tailored to the needs of the programmer. With the new release, this should be doable. Hope this helps. Also, related to VOSIM: FOF's - we hope to put up some examples soon. Best, Ge!

From: paul.maddox.mail-list@synth.net Subject: [chuck] New guy, and questions Date: Tue, 22 Mar 2005 13:31:06 +0000 Message-ID: <1111498266.42401e1a8b135@webmail.synth.net>

All,

Paul, So you finally come over here too! ;O)

Now I can see I can use a sine oscillator, square it and this will give me the bell curve, only problem here is that I get two 'bell curves' for the price of one cycle, which brings me neatly onto my next problem..

Notice that squaring the sine gives you a DC-shifted sine of double frequency.

What I need to do is to change the amplitude and/or pitch of each 'pulse' at the zero crossing, great I can use Zerox, but, how do I then change the value?

I had though of feeding the output of Zerox into a 'sequencer' which controls the pitch and amplitude of the sine oscillator, but I can't see a 'sequencer' type of module..

As always in chuck, if it ain't there, you program it! Straigh chuck-code will do.

So, There are two questions firstly, Is there a sequencer module planned? and secondly, if not, how can I get round this? can I use the output of Zerox to increase a counter and use an 'if' statement to change the values of the sine oscillator? will the use of multiple 'if' statements be quick enough?

I've been pondering over doing a generalized sequencer. However, the feature that I lack is the ability to have a number of control-values that I either control manually or have control signals fiddeling around with. I want to unplugg things and hook things up independently with the execution of that sproc. Some work has been going on to investigate that over here, but I don't know what has happend in 1.2 in relation to that. The modulars/Synthi-A sense of plugging and unplugging/rerouting signals as they go on is powerfull and how one works in real life. On the Synthi-A one naturally "plays" by just briefly patch in one of the patch-pins into the matrix. Infact, just having that patchability in graphics would be cool, but I'd guess the OpenGL interface is doomed to do that work, no? Cheers, Magnus