Cheng Chien-Wen

I have seen many patches, like harmonizer, or FFT overlapping things, using cycle~ to read a buffer and to make the two same signals out of phase. I was told this will "smooth" out unwanted abruptness in the sound.

But I never really know why we use cycle~ to read the buffer instead of using index~ or something else. I also don't know why FFT frames can be smoothed out when "cycle~ buffer" is made "out of phase" to respectively multiply the two same output signal from ifft.

I have read the manuals, papers, and Computer Music Tutorial, but I only know they should be performed this way and never know why they use "cycle~" and what is so good about "out of phase". I know what they want to achieve but does not know why and how they can achieve what they want by performing this.

Can someone explain this a little bit or suggest some good textbooks that explain the basics of this.

I have seen many patches, like harmonizer, or FFT overlapping things, using cycle~ to read a buffer and to make the two same signals out of phase. I was told this will "smooth" out unwanted abruptness in the sound. 

But I never really know why we use cycle~ to read the buffer instead of using index~ or something else. I also don't know why FFT frames can be smoothed out when "cycle~ buffer" is made "out of phase" to respectively multiply the two same output signal from ifft. 

why-use-cycle-to-perform-overlapping-thing

Quote: Cheng Chien-Wen wrote on Sat, 26 August 2006 14:12

----------------------------------------------------

> But I never really know why we use cycle~ to read the buffer instead of using index~ or something else.

index~ does not interpolate, and cycle~ does.

> I have read the manuals, papers, and Computer Music Tutorial, but I only know they should be performed this way and never know why they use "cycle~" and what is so good about "out of phase". I know what they want to achieve but does not know why and how they can achieve what they want by performing this.

> Can someone explain this a little bit or suggest some good textbooks that explain the basics of this.

http://www.lds-group.com/docs/site_documents/AN014%20Understanding%20FFT%20Windows.pdf#search=%22fft%20window%20choosing%22

Although I have to admit that, as a musician, I've conciously *not* developed a deep understanding of the mathematical implications of fft windowing.

Quote: Cheng Chien-Wen wrote on Sat, 26 August 2006 14:12
----------------------------------------------------
> But I never really know why we use cycle~ to read the buffer instead of using index~ or something else. 

> I have read the manuals, papers, and Computer Music Tutorial, but I only know they should be performed this way and never know why they use "cycle~" and what is so good about "out of phase". I know what they want to achieve but does not know why and how they can achieve what they want by performing this.
>
> Can someone explain this a little bit or suggest some good textbooks that explain the basics of this.
>

Thanks for the info. What I really want to know is why we use cycle~ (a sine wave oscillator) to read a buffer. You mentioned above the interpolation thing, but I still don't understand how a sine wave can be used to read a lookup table in the buffer since a sine wave go from above 0 to below 0 periodically.

This seems to be very abstract to me. However, harmonizer, granular synthesis, FFT synthesis all use the same strategy. Even though I began to get used to it when I saw it, I won't be able to explain to my students why and how a "sine wave" can read a lookup table in the buffer, and why they can smooth out the sound.

Are there any simple way or patch to see and compare what actually happens in Max/MSP when this process is applied ?

Hi, 
Thanks for the info. What I really want to know is why we use cycle~ (a sine wave oscillator) to read a buffer. You mentioned above the interpolation thing, but I still don't understand how a sine wave can be used to read a lookup table in the buffer since a sine wave go from above 0 to below 0 periodically.

Are there any simple way or patch to see and compare what actually happens in Max/MSP when this process is applied ? 

Ok, after reading the the documentation you offer, I know better about overlapping thing and know how to explain it to someone else. But still would like to know why a sine wave (cycle~) which moves from above 0 to below 0 should be used to read a lookup table in addition interpolation thing.

> But still would like to know why a sine wave (cycle~) which moves 

> from above 0 to below 0 should be used to read a lookup table in 

i'm not sure which example you are refering to, but it seems you've 

cycle~ itself is a table lookup object, it is normally not used to 

as long as you don't specify a valid buffer name as an argument to 

cycle~, it simply uses it's internal table (buffer) which contains a 

if you perform some kind of windowing technique, you normally want to 

use a certain windowing function (von han, hamming, blackman etc.) 

which you can write into a buffer. this buffer can then be used by a 

> But still would like to know why a sine wave (cycle~) which moves  
> from above 0 to below 0 should be used to read a lookup table in  
> addition interpolation thing.

i'm not sure which example you are refering to, but it seems you've  
got the wrong idea about it.
cycle~ itself is a table lookup object, it is normally not used to  
read another lookup-table.
as long as you don't specify a valid buffer name as an argument to  
cycle~, it simply uses it's internal table (buffer) which contains a  
cosine wave.
if you perform some kind of windowing technique, you normally want to  
use a certain windowing function (von han, hamming, blackman etc.)  
which you can write into a buffer. this buffer can then be used by a  
cycle~ object as a lookup-table.
all this is covered in cycle~.help
hope this helps,
volker.


Thanks for the explanation. But I am still a little bit confused about the concept of "table look-up oscillator".

What are the differences between "cycle~ buffer" and "groove~ buffer" conceptually ? 

Both of them in my understanding read the buffer, "loop" the buffer data, send out audio signal. What are the basic differences between them ?

My question is probably very silly:
What are the differences between "cycle~ buffer" and "groove~ buffer" conceptually ? 
Both of them in my understanding read the buffer, "loop" the buffer data, send out audio signal. What are the basic differences between them ?

It helps to think that cycle~ is an *oscillator* rather than a sample player. As was previously stated, it can cycle its default sine function wavetable, which is 512 samples in length, or it can read a function from another wavetable. But it is an oscillator, pure and simple. The idea is that it loops through just one cycle of a function (wave form) at the frequency determined by the user.

On the other hand, groove~, play~, wave~ are designed to work within a buffer that is x samples long and can contain complex waveforms. The user can use these to manipulate the playback of sound data stored in a buffer~ in a variety of ways, and doesn't specify playback by frequency of loop, but instead by speed, which is ratio driven dependent on the sample rate of the material in the buffer and the sample rate of the playback. These objects have many options, such as multiple outputs, etc. In this usage, the buffer~ typically contains complex sound material of x length rather than a single cycle of a function.

cycle~ is good for function-based wave forms (sine waves, etc) and windowing functions, all of which can be contained a wavetable that represents a single cycle, and whose frequency can be explicitly set. With these, you want the same function repeated over and over without variation. While cycle~ can contain any kind of function, other oscillators are provided that are optimized for certain functions, like phasor~, tri~, rect~, and saw~.

While these two categories of the use of buffer~ are quite different, the same buffer~ object works for both.

It helps to think that cycle~ is an *oscillator* rather than a sample player.  As was previously stated, it can cycle its default sine function wavetable, which is 512 samples in length, or it can read a function from another wavetable.  But it is an oscillator, pure and simple.  The idea is that it loops through just one cycle of a function (wave form) at the frequency determined by the user.

On the other hand, groove~, play~, wave~ are designed to work within a buffer that is x samples long and can contain complex waveforms.  The user can use these to manipulate the playback of sound data stored in a buffer~ in a variety of ways, and doesn't specify playback by frequency of loop, but instead by speed, which is ratio driven dependent on the sample rate of the material in the buffer and the sample rate of the playback.  These objects have many options, such as multiple outputs, etc.  In this usage, the buffer~ typically contains complex sound material of x length rather than a single cycle of a function.

cycle~ is good for function-based wave forms (sine waves, etc) and windowing functions, all of which can be contained a wavetable that represents a single cycle, and whose frequency can be explicitly set.  With these, you want the same function repeated over and over without variation.  While cycle~ can contain any kind of function, other oscillators are provided that  are optimized for certain functions, like phasor~, tri~, rect~, and saw~.

While these two categories of the use of buffer~ are quite different, the same buffer~ object works for both.


>cycle~ is good for function-based wave forms (sine waves, etc) and 

>windowing functions, all of which can be contained a wavetable that 

>represents a single cycle, and whose frequency can be explicitly 

>set. With these, you want the same function repeated over and over 

>without variation. While cycle~ can contain any kind of function, 

>other oscillators are provided that are optimized for certain 

>functions, like phasor~, tri~, rect~, and saw~.

but it is also fun to use a buffer of "some sound" for cycle~ - 

depending where in this buffer you read your 512 samples (or is it 

513??? i read than the extra sample is used to interpolate.....) the 

>
>cycle~ is good for function-based wave forms (sine waves, etc) and 
>windowing functions, all of which can be contained a wavetable that 
>represents a single cycle, and whose frequency can be explicitly 
>set.  With these, you want the same function repeated over and over 
>without variation.  While cycle~ can contain any kind of function, 
>other oscillators are provided that  are optimized for certain 
>functions, like phasor~, tri~, rect~, and saw~.
>

but it is also fun to use a buffer of "some sound" for cycle~ - 
depending where in this buffer you read your 512 samples (or is it 
513??? i read than the extra sample is used to interpolate.....) the 
sound of your oscillator changes

kasper
-- 
  Kasper T. Toeplitz
noise, composition, bass, computer
http://www.sleazeArt.com

Quote: Cheng Chien-Wen wrote on Sat, 26 August 2006 22:20

> Thanks for the info. What I really want to know is why we use cycle~ (a sine wave oscillator) to read a buffer. You mentioned above the interpolation thing, but I still don't understand how a sine wave can be used to read a lookup table in the buffer since a sine wave go from above 0 to below 0 periodically.

dont look at cycle as a "sine wave oscillator" -

it is a "table". it can produce a triwave or whatever 

what is useful using cycle~ is that if you need a bipolar 

sinewave, this waveform is in it the default, so that you do not

from above 0 to below 0 ? well negative values will read

not sure if that explains it any better, but i think 

what mzed means is that when you give cycle~ a float 

number, it interpolates this number internally to output 

a bit more correct values than index~ would.

basically you could reproduce your own cycle thing with

index/buffer, or with groove, but it will be less exact

when you modulate the reading speed in such a system,

Quote: Cheng Chien-Wen wrote on Sat, 26 August 2006 22:20
----------------------------------------------------
> Hi, 
> Thanks for the info. What I really want to know is why we use cycle~ (a sine wave oscillator) to read a buffer. You mentioned above the interpolation thing, but I still don't understand how a sine wave can be used to read a lookup table in the buffer since a sine wave go from above 0 to below 0 periodically.

dont look at cycle as a "sine wave oscillator" -
it is a "table". it can produce a triwave or whatever 
you want it to.

what is useful using cycle~ is that if you need a bipolar 
sinewave, this waveform is in it the default, so that you do not
have to generate a curve by yourself.

from above 0 to below 0 ? well negative values will read
a buffer backwards.

not sure if that explains it any better, but i think 
what mzed means is that when you give cycle~ a float 
number, it interpolates this number internally to output 
a bit more correct values than index~ would. 

basically you could reproduce your own cycle thing with
index/buffer, or with groove, but it will be less exact
when you modulate the reading speed in such a system,
which is why everyone is using cycle~

Quote: Kasper T Toeplitz wrote on Sun, 27 August 2006 15:53

> but it is also fun to use a buffer of "some sound" for cycle~ - 

> depending where in this buffer you read your 512 samples (or is it 

> 513??? i read than the extra sample is used to interpolate.....) the 

> sound of your oscillator changes quite nice

Right, a table-lookup oscillator usually adds one sample to the end for interpolation--my assumption is that cycle~ is no exception. Sure, you can draw your own complex wave, or use 512 samples from anywhere, and perhaps with interesting results. I've personally stuck to using cycle~ the old-fashioned way--to oscillate simple functions.

Quote: Kasper T Toeplitz wrote on Sun, 27 August 2006 15:53
----------------------------------------------------
> but it is also fun to use a buffer of "some sound" for cycle~ - 
> depending where in this buffer you read your 512 samples (or is it 
> 513??? i read than the extra sample is used to interpolate.....) the 
> sound of your oscillator changes quite nice
----------------------------------------------------
Right, a table-lookup oscillator usually adds one sample to the end for interpolation--my assumption is that cycle~ is no exception.  Sure, you can draw your own complex wave, or use 512 samples from anywhere, and perhaps with interesting results.  I've personally stuck to using cycle~ the old-fashioned way--to oscillate simple functions.

why use cycle~ to perform overlapping thing ?