Re: [PD] Creating a basic oscillator from first principles?
Hallo, Geoff hat gesagt: // Geoff wrote: Just a few things I need to clarify The frequency of the phasor is determined by the slope of the line, by the phase increment k. If y=mx +k and wrapping this produces an oscillator, I understand that adding k can be the phase increment i.e. what point the waveform will start from, The phase increment is not where the waveform starts but the amount it advances each time step. So the phase increment would be m in the equation y = mx + k. You can ignore k for phasor~-like signals, it always is zero. y = mx + k is a linear equation - see http://en.wikipedia.org/wiki/Line_(geometry) Does this mean that in this example the [*~ 3] object represents m and therefore the frequency of the oscillator and you would add a [+~ ] to control the phase increment? The [*~ 3] is a frequency multiplier. If you multiply a phasor signal by x and then wrap it, you get a phasor signal with x times the base frequency. You can see this in the example in that the vline~ produces a burst of three spikes, although it itself is only doing a single ramp. If you add anything to that signal with [+~] you don't change the frequency, only the offset from the x-axis i.e. the DC offset or the start of a sample in a phasor-driven [tabread4~]-sampler. In practice, in code, we combine the integrator and wrap into a single unit so that the line does not increase without bound. If it does then the oscillator will work for a while, but then the line will exceed the representation range of the CPU. Am I understanding you correctly in thinking that the integrator and wrap and combined so that rather than leave the integrator to keep counting higher and higher (unitl the processor can't cope) the wrap function is somehow combined with it so that the integrator keeps reseting itself so that the number it counts up to never gets that big? In Andy's patches the wrap~ is not resetting the integrators, but in the source code for [phasor~] in Pd, the integrator indeed is reset. Btw: If you're like me and are always having difficulties reading [biquad~] coefficients: In Andy's patch you could also use [rpole~ 1] instead of the biquad. rpole calculates this: y[n] = y[n-1] + a[n] * x[n] so if a == 1 it calculates: y[n] = y[n-1] + x[n] which means, it constantly adds the new input to the old output to produce the next output which is integration. Ciao -- Frank BarknechtDo You RjDj.me? _ __footils.org__ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Creating a basic oscillator from first principles?
Thanks for the example patch I am almost getting perhaps close to understanding :) However have a few queries about what is happening. I have been trying to work out the wrapping a vline patch first as this seems the most straightforward, as this is all really new to me. So first off [r x] object receives a bang from the x subpatch every 200 milliseconds. This bang then outputs the message [0, 1 10] every 200 millisecond The message [0,1 10] means go from 0 to 1 in 10 milliseconds this message then goes into the vline object which creates the ramp (sawtooth) i.e. the y=mx equation that you mentioned where the 10 milliseconds could be the gradient of the sawtooth waveform or the gradient could be later on. The output of the vline object is then multiplied by 3 which in effect multiplies the steepness of the slope by 3 This multiplication could be the m in the equation y=mx and seems like a more logical place than in the ramp. This is then wrapped to keep the output cycling to 1. So in effect we get 3 sawtooth waveforms for each bang sent by x which occurs every 200milliseconds. and now I have an oscillator :) Just a few things I need to clarify The frequency of the phasor is determined by the slope of the line, by the phase increment k. If y=mx +k and wrapping this produces an oscillator, I understand that adding k can be the phase increment i.e. what point the waveform will start from, Does this mean that in this example the [*~ 3] object represents m and therefore the frequency of the oscillator and you would add a [+~ ] to control the phase increment? In practice, in code, we combine the integrator and wrap into a single unit so that the line does not increase without bound. If it does then the oscillator will work for a while, but then the line will exceed the representation range of the CPU. Am I understanding you correctly in thinking that the integrator and wrap and combined so that rather than leave the integrator to keep counting higher and higher (unitl the processor can't cope) the wrap function is somehow combined with it so that the integrator keeps reseting itself so that the number it counts up to never gets that big? Once again thankyou for this example, I don't know if you are a lecturer and this is an example you use. Its really helped me visualize things. cheers Geoff On 7 Feb 2009, at 19:07, Andy Farnell wrote: Here's some notes and an example patch on exactly this subject hope it helps. a. snip-- The first principles of generative DSP can be broken into three concepts which follow easily from one another. The first and most fundamental is that of the accumulator. This just means something like x = x + 1 Or more correctly x[t_n] = x[t_n-1] + k It just makes a line. The line increases without bound. From high school maths you will know the line equation y = mx + c, the slope m determines how fast the line rises from an origin c on the y axis for a given interval on the x axis. In DSP we make the x axis be time, t, and the discrete time values n and n-1 represent contiguous samples along the time line. In a simple sense of programming the accumulator/incrementor/ integrator can be considered an endless loop, a do-while(1) or for(;;;) loop, in which a variable is incremented by a small amount on each step. In a more advanced interpretation the accumulator/incrementor can be thought of as a filter, an IIR filter in which the current output depends on the last output plus input k, so it integrates k over time. Thus by changing k we can change the slope (slew or phase increment) of the line. Shown in part one of the example patch is a couple of ways of doing this. The first uses [vline~] to make a line that will rise steadily over a long period of time. The second is more arcane, it uses a [biquad~] object as an integrator. This isn't much use until we combine it with the second fundamental concept, the idea of wrapping. Wrapping creates a discontinuous periodic function by making any input value x greater than N become 0 x N, wrapping the output back into the range between zero and N. If x is a float then it's the fractional part of x, or x - floor(x), like the modulo operator is to integers. In Pure Data it is defined for the range 0 to 1.0. What we get by combining an accumulator with a wrap is called a phasor, a line that cycles up from 0.0 to 1.0 over and over. The frequency of the phasor is determined by the slope of the line, by the phase increment k. In practice, in code, we combine the integrator and wrap into a single unit so that the line does not increase without bound. If it does then the oscillator will work for a while, but then the line will exceed the representation range of the CPU. A wrapped line is shown in the second part of
[PD] Creating a basic oscillator from first principles?
Hi I am very new to PD and DSP concepts. So this will be hopelessly, awfully, basic :) I have just started chapter 3 of 'The theory and technique of electronic music' which is excellent However it raises a million questions in my head.. one of which is how do I create an oscillator myself? Its really bugging me everytime I create an example from the book. I feel I need to understand the fundamentals of how the basic objects are created too. It seems too easy for me to just use the phasor object provided, So I thought I would struggle through it and try to work it out. This is how I am thinking about it. If I want to create a sawtooth oscillator then this is just a ramp function i.e. a number that increases by 1 each time. therefore if I use a simple float that, that adds 1 each time and a modulus % object to cap it, then I will have my repeating ramp wave :) However I am triggering it by the metro object which is way too slow, how can I send a bang to the float object say every sample? or alot quicker than one millisecond? My thinking is if I could speed up the bangs to a sample level I would then have more scope to then actually tune it, and create the shape I want. However I am sure to do this well would require working at a higher sample rate, but I am not really sure how to proceed. Below is my appalling attempt :) I use the number box to change pitch. Any guidance appreciated Cheers Geoff #N canvas 325 62 681 388 10; #X obj 119 69 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 121 96 f; #X obj 181 116 + 1; #X obj 115 17 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 127 238 dac~; #X obj 118 46 metro 1; #X floatatom 187 163 5 0 0 0 - - -; #X obj 115 160 %; #X obj 114 199 /; #X connect 0 0 1 0; #X connect 1 0 2 0; #X connect 1 0 7 0; #X connect 2 0 1 1; #X connect 3 0 5 0; #X connect 5 0 0 0; #X connect 6 0 7 1; #X connect 6 0 8 1; #X connect 7 0 8 0; #X connect 8 0 4 0; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Creating a basic oscillator from first principles?
Hallo, Geoff hat gesagt: // Geoff wrote: Its really bugging me everytime I create an example from the book. I feel I need to understand the fundamentals of how the basic objects are created too. It seems too easy for me to just use the phasor object provided, But that's much more effective. So I thought I would struggle through it and try to work it out. This is how I am thinking about it. If I want to create a sawtooth oscillator then this is just a ramp function i.e. a number that increases by 1 each time. therefore if I use a simple float that, that adds 1 each time and a modulus % object to cap it, then I will have my repeating ramp wave :) Yes, that's correct. You should not use a graphical bang here, as that is a huge (!) waste of ressources. Anyway generally you can make your approach a bit simpler, too. Instead of always adding 1 and scaling plus restricting your counter to a large value, you can also add a smaller value and restrict the output to lie between 0 and 1. Example: Say you add one and always go to f=100: x[n+1] = [(x[n] + 1) % f] / f x[n+1] = [(x[n] + 1) % 100] / 100 Then instead you can also do this: x[n+1] = [(x[n]/f + 1/f) % f/f] x[n+1] = (x[n]/100 + 1/100) % 1 or, as x[n] is restricted anyway do: phasor = (x[n] + 1/100) % 1 The 1/f part is called the phase increment. Note that you need to use a kind of fmod for floating point numbers here, i.e. replace the % with a calculation to get the fractional part: fractional part of f = f - int(f) Also add an additional 1 if you deal with negative numbers. However I am triggering it by the metro object which is way too slow, how can I send a bang to the float object say every sample? or alot quicker than one millisecond? Use a [phasor~] ;-) You can also built your own fast metro using feedbacked [delay] objects. I posted one a while ago here. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Creating a basic oscillator from first principles?
Thanks Frank this all makes sense up to Note that you need to use a kind of fmod for floating point numbers here, i.e. replace the % with a calculation to get the fractional part: fractional part of f = f - int(f) Also add an additional 1 if you deal with negative numbers. I can see from experimenting in PD that % doesn't want to behave the same for decimal numbers. i.e. if I set % to 1 and increment (x[n] + 1/100) % 1 nothing happens so I need some sort of fmod to deal with the fact that now the values I am generating range from 0 to 1 in 0.01 increments. could you expand on fractional part of f = f - int(f) i.e. because I need to limit things to 1 the % 1 is not going to work so I need a different function that will do the same thing for decimals limited to 1. how would I approach that in PD? Thanks for the input geoff However I am triggering it by the metro object which is way too slow, how can I send a bang to the float object say every sample? or alot quicker than one millisecond? Use a [phasor~] ;-) You can also built your own fast metro using feedbacked [delay] objects. I posted one a while ago here. Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/ listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Creating a basic oscillator from first principles?
Hallo, Geoff hat gesagt: // Geoff wrote: Thanks Frank this all makes sense up to Note that you need to use a kind of fmod for floating point numbers here, i.e. replace the % with a calculation to get the fractional part: fractional part of f = f - int(f) Also add an additional 1 if you deal with negative numbers. I can see from experimenting in PD that % doesn't want to behave the same for decimal numbers. i.e. if I set % to 1 and increment (x[n] + 1/100) % 1 nothing happens so I need some sort of fmod to deal with the fact that now the values I am generating range from 0 to 1 in 0.01 increments. could you expand on fractional part of f = f - int(f) it's simply: [t f f] | / | [int] | | [- ] Check out the message phasor in the RjDj library for a full implementation: http://trac.rjdj.me/browser/trunk/rjlib/rj/c_mphasor.pd http://trac.rjdj.me/browser/trunk/rjlib/rj/c_mphasor-help.pd Ciao -- Frank ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
