Search results

If by "sample size" you mean "sampling rate" then yes.

There should be a "Best IRC chatlog" category. Unfortunately, I have no nominations for it at the moment.

The oscillator is basically a device that takes a speed as input, and cycles through the real numbers in the interval [0,1) at that speed. In theory, it's continuous, and hits every real number in that interval, but in practice, it's discrete, and only hits a finite number of them. You can...

And I think that's enough for now. Fo sho bro mo fo - the movie.

We update our block diagram to the following:

This is convenient because it means that our pitch input is simply the number of cycles per second, which is the frequency of the sound we want in Hz.

We can figure out such a calculation using dimensional analysis, like so: (cycles/second) / (sample frames/second) = (cycles/sample frame)

To summarize, we need to do some calculation involving the sampling rate (sample frames/second), which gives us the input to the oscillator (cycles/sample frame).

In order make the outputted pitch independent of the sampling rate, we will need to take the sampling rate into consideration. We will need to introduce a new device which takes no inputs and constantly outputs the sampling rate in sample frames per second.

The thing to note about the oscillator device is that its input is measured in cycles per sample frame. For example, if you send it a constant input of .1, you are saying that you want it to move one tenth of the way through its cycle every sample frame.

One issue with the way pitch is currently set up is that it's dependent on the sampling rate. In other words, changing the sampling rate will change the pitch of the note produced, even if the inputs remain exactly the same. This should be avoided.

The way this is currently set up, controlling the volume is fairly intuitive; you simply specify a number from 0 to 1. Pitch, however, is not so intuitive. Let's see if we can make it more so.

Our block diagram now looks like this:

If you open that wav file in a program that allows you to see the waveform (i.e. Audacity, ptnoise), you'll notice it never drops below the midpoint (0), since our oscillator outputs values in the interval [0,1), but really should go all the way down to -1. To fix this we simply take the output...

Note that, rather than using integer values to represent sample frames (as is done in the actual wav file), we are using floating point values in the interval [-1,1). To convert these to their integer counterparts would be a simple matter of multiplying them by either 128 or 32768, depending on...

http://www.mediafire.com/?lqqf5h2tld65k8t This is what the output from our example sounds like at the typical sampling rate of 44100 sample frames per second.

In Pixel's pxt editor, he calls it a ramp. I sometimes like to call it the "stock market waveform".

This waveform, where it rises and then suddenly drops repeatedly, is fairly common and is called a sawtooth wave.

In other news, I probably should have just written a program to generate that image rather than slaving away in mspaint for a half hour... >_>

So, suppose the inputs were: "pitch=.08, volume=.5". The graph of the output over time would look like this:

Finally, the state is outputted.

The state is then updated to fit within the interval [0,1) by repeatedly adding or subtracting 1 (i.e. 1.3 becomes .3, -.4 becomes .6, etc.).

It has an internal state which is also a numeric value in the interval [0,1). During each virtual "clock cycle" of the synthesizer (each of which corresponds to exactly one sample frame of audio output) the input value is first added to the internal state.

The output of an oscillator (at least in the way I'm defining it for now) will always be in the interval [0,1).