Ryan Lieber

I programmed a sine oscillator in gen~ that works fine when the input frequency in Hz is greater than "1.0". However, when the input frequency is less than "1.0" (e.g. 0.5), the gen~ oscillator looks like it's being re-triggered when the amplitude value hits "-1.0".

A regular phasor~ to cos~ connection is shown for comparison's sake. Hopefully the included pictures illustrate what I mean.

Any ideas on what am I missing in my gen~ oscillator?

Gen-Osc.png

Comparison-1.png

Comparison-2.png

I programmed a sine oscillator in gen~ that works fine when the input frequency in Hz is greater than "1.0".  However, when the input frequency is less than "1.0" (e.g.  0.5), the gen~ oscillator looks like it's being re-triggered when the amplitude value hits "-1.0". 

A regular phasor~ to cos~ connection is shown for comparison's sake. Hopefully the included pictures illustrate what I mean. 

Any ideas on what am I missing in my gen~ oscillator?
Thanks!!!

Hi!
I programmed a sine oscillator in gen~ that works fine when the input frequency in Hz is greater than "1.0". 

gen~-sinusoidal-oscillator-is-re-triggering-for-some-reason

by using 'counter' that way, you end up putting the multiplier in the wrong place(you could use counter if you feed it the fractional value [1]->[/ samplerate] and then multiply that before going into counter)... i prefer the accumulator op since it feels simpler:

Screenshot 2023-01-26 at 5.17.16 PM.png

but here's that same patch with counter just to be complete:

(and i used the 'sin' op since we're talking about sine waves, but they basically sound the same ...the difference is mainly when you hard-sync... and i put the click~ and phasor~ in to show that as well - [edit: just to avoid confusion, figured i should also mention that the phasor~ scope is set to range 0. and 1. while gen~-sin is set to a range of -1. and 1. in the above patch unlike in my pic])

by using 'counter' that way, you end up putting the multiplier in the wrong place(you could use counter if you feed it the fractional value [1]->[/ samplerate] and then multiply that before going into counter)... i prefer the accumulator op since it feels simpler:


but here's that same patch with counter just to be complete:


Yo Raja, thanks for the help! I see what you mean about the count or accumulation beginning after the multiplication.

Why that matters, I definitely don't know haha. I'm still a beginner at this level of DSP and math. :)

ah, no worries, i should explain that part better:

-first, when driving a sine oscillator in radians, the count being multiplied by 'twopi' will act on the phase of the sine-oscillator as if wrapping anything outside the range of twopi, back within it; this is the magic of 'radians' - they radiate in a circle when they apply to phase :)... (for example, "6 * π " is the same as "2 * π", "-5.2 * π" is the same as "-1.2 * π"(5.2/2 = 2 with remainder 1.2, and then you just account for the negative-sign... not to go off to much on this tangent, but negative radians is simply the same as negative-phase... add a [wrap -pi pi] after the [* twopi], you'll notice there's no difference in behavior), etc.)

-given the above point, you don't want a ramp from 0 to 1, multiplied by 'twopi', to fail at completing the full ramp(when it doesn't span the complete distance of twopi before resetting back to 0, it will have the effect of resetting the phase of your sine-oscillator)

-by working in fractional increments relative to the duration of a single sample at your samplerate(1/samplerate), and then multiplying that by the frequency desired simply to stretch the duration of each sample-increment, the 'counter/accum/+=' ops will be allowed to count upward continuously(and you'll never end up breaking the progression between 0 and twopi), thus allowing the phase of your sine-oscillator to be ever-continuous as well

(^reading that all back, i realize i'm a bit wordy haha, not quite the 'scholar' in terms of my semantics, apologies, but hopefully it makes sense, and if not, i usually get this far on DSP, just by working example values through each part of the dsp-chain... so at the point where you might multiply a ramp from 0 to 1, by 0.5, it would only go from 0. to 0.5, then from there from 0 to π(instead of the full range of twopi), and then it was easy to see how it would break the phase of the sine from there... working backwards, you'd then just figure out how to make the count continous: by allowing a multiplier to only change the increment fed in by which it counts, and not allowing a drastic change to occur at the output of the count itself)

ah, no worries, i should explain that part better:
-first, when driving a sine oscillator in radians, the count being multiplied by 'twopi' will act on the phase of the sine-oscillator as if wrapping anything outside the range of twopi, back within it; this is the magic of 'radians' - they radiate in a circle when they apply to phase :)... (for example, "6 * π " is the same as "2 * π", "-5.2 * π" is the same as "-1.2 * π"(5.2/2 = 2 with remainder 1.2, and then you just account for the negative-sign... not to go off to much on this tangent, but negative radians is simply the same as negative-phase... add a [wrap -pi pi] after the [* twopi], you'll notice there's no difference in behavior), etc.)

-given the above point, you don't want a ramp from 0 to 1, multiplied by 'twopi', to fail at completing the full ramp(when it doesn't span the complete distance of twopi before resetting back to 0, it will have the effect of resetting the phase of your sine-oscillator)

-by working in fractional increments relative to the duration of a single sample at your samplerate(1/samplerate), and then multiplying that by the frequency desired simply to stretch the duration of each sample-increment, the 'counter/accum/+=' ops will be allowed to count upward continuously(and you'll never end up breaking the progression between 0 and twopi), thus allowing the phase of your sine-oscillator to be ever-continuous as well

Hey Raja, thanks for your explanation! It may not sound 'academic' but it sure is helpful to me. To question and to clarify...

Is the value after 'twopi' considered a radian? Not a degree?

Is the value after 'sin' considered an amplitude?

Is essentially the whole 'game' of oscillators just turning radians into amplitudes but in a sample-to-sample fashion via some accumulator or counter type function? Or is it about turning 'angular frequencies' into amplitudes. It seems radians and angular frequencies are almost interchangeable?

Hey Raja, thanks  for your explanation! It may not sound 'academic' but it sure is helpful to me. To question and to clarify...

correct! to answer another question you asked: 0 to 'twopi' could be said to 

 degrees from 0º to 360º... but the actual input going to 'sin'/'cos' is in 'radians' ...this is how they are interchangeable in reference, but not in usage. while you'd just have to scale '0 to twopi' into the range of '0 to 360' if you wanted degrees... 'sin' and 'cos' work directly with radians because they're functions which trace the radius around a unit circle.

this video might explain that better than i could(but i recommend going to the 'settings' icon near bottom right of the video, and playing it at 1.5 speed to save you time :D):

yes, exactly... (an amplitude between -1 and 1, how you use 'amplitude' depends on context too:

this is why i don't claim to be 'scholarly': there are others who might be able to give you a clearer definition that might govern all contexts(i also get confused often because when working with FFT, you'll find 'magnitude' is very similar, but not exactly the same).

short answer: you could say this about working with functions being generated to 'oscillate' within a specific range, in real-time within a digital-system that runs at a specific sample-rate(such as using sin/cos/etc. to 'generate' the values per-sample)... and just to be clear, the radians aren't turned directly into amplitudes but rather used to drive a function(usually trigonometric in nature) which will then draw out or stream a specific shape of amplitude.

but long answer: i hesitate to summarize the whole game even there, as you'll run into other contexts such as wavetables where they can serve as oscillators, but might just take 'phase' from 0 to 1; see the 'cycle' op within gen~, it can be changed with the @index attribute to be driven by 'phase'(in which case you're connecting an external accumulator such as 'phasor', or anything you can create which would ramp or traverse the range between 0 and 1)... even their terminology there is slightly confusing... when you option/alt-click on the op to get quick-help on it, it claims it defaults to being 'driven by a frequency input', but the word 'driven' in this case means two completely different things, really what they mean is that you can either 'control' the frequency by default(in that case, it will be 'driven' by an internal phase-accumulator), or you can 'drive' the phase of its internal wavetable from the outside, using a connected phasor:

Screenshot 2023-01-31 at 1.28.58 PM.png

here's a patch that can show some of the things i've been mentioning so far a bit better:

...then there's various types of other oscillators which don't necessarily need to work this way depending on how you construct them(i.e. lfo oscillators, or chaotic oscillators(which would introduce chaos to break up the symmetry/asymmetry a bit), or oscillators which don't need to work within audio ranges, could therefore use other methods beyond accumulators - 'strange attractors' are a bit like this, they can be said to 'oscillate' at times depending on their settings, and are also somewhat chaotic by nature).

but basically, while an 'oscillator' can be anything that oscillates between a high and low value, i think you understand it perfectly as it applies to making oscillators from real-time generated functions such as 'sin'/'cos' within a digital/sample-based system 👍

Also, the 'GO' book here is one of the best i've found to help understand much of this at a more in-depth level, i'd also describe it as falling at a nice 'intermediate' level where both beginners and advanced will gain a lot from reading it:

(chapter 3 in particular helps you build oscillators from 'sin'/'cos'/'phasor'/'triangle' to form many more shapes than just the basic ones)

correct! to answer another question you asked: 0 to 'twopi' could be said to represent degrees from 0º to 360º... but the actual input going to 'sin'/'cos' is in 'radians' ...this is how they are interchangeable in reference, but not in usage. while you'd just have to scale '0 to twopi' into the range of '0 to 360' if you wanted degrees... 'sin' and 'cos' work directly with radians because they're functions which trace the radius around a unit circle.
this video might explain that better than i could(but i recommend going to the 'settings' icon near bottom right of the video, and playing it at 1.5 speed to save you time :D):

yes, exactly... (an amplitude between -1 and 1, how you use 'amplitude' depends on context too:
https://en.wikipedia.org/wiki/Amplitude )
this is why i don't claim to be 'scholarly': there are others who might be able to give you a clearer definition that might govern all contexts(i also get confused often because when working with FFT, you'll find 'magnitude' is very similar, but not exactly the same).

Is essentially the whole 'game' of oscillators just turning radians into  amplitudes but in a sample-to-sample fashion via some accumulator or  counter type function?

but long answer: i hesitate to summarize the whole game even there, as you'll run into other contexts such as wavetables where they can serve as oscillators, but might just take 'phase' from 0 to 1; see the 'cycle' op within gen~, it can be changed with the @index attribute to be driven by 'phase'(in which case you're connecting an external accumulator such as 'phasor', or anything you can create which would ramp or traverse the range between 0 and 1)... even their terminology there is slightly confusing... when you option/alt-click on the op to get quick-help on it, it claims it defaults to being 'driven by a frequency input', but the word 'driven' in this case means two completely different things, really what they mean is that you can either 'control' the frequency by default(in that case, it will be 'driven' by an internal phase-accumulator), or you can 'drive' the phase of its internal wavetable from the outside, using a connected phasor:


...then there's various types of other oscillators which don't necessarily need to work this way depending on how you construct them(i.e. lfo oscillators, or chaotic oscillators(which would introduce chaos to break up the symmetry/asymmetry a bit), or oscillators which don't need to work within audio ranges, could therefore use other methods beyond accumulators  - 'strange attractors' are a bit like this, they can be said to 'oscillate' at times depending on their settings, and are also somewhat chaotic by nature).

Also, the 'GO' book here is one of the best i've found to help understand much of this at a more in-depth level, i'd also describe it as falling at a nice 'intermediate' level where both beginners and advanced will gain a lot from reading it:
https://cycling74.com/books/go 
(chapter 3 in particular helps you build oscillators from 'sin'/'cos'/'phasor'/'triangle' to form many more shapes than just the basic ones)


Hey Raja, sorry for the late reply, but I need at least a few days to read and digest your replies lol. Surprisingly, everything you're saying makes sense!

You've definitely opened a can of worms in your patch by including a low pass filter, something I know very little about.

Is filter design a pretty logical thing to learn alongside oscillator design? I assume there's a lot of overlap in regards to calculus-type functions? I guess filters are where you start running into delay lines? Oscillators in and of themselves don't really rely too much on delay lines, I suppose?

I was pondering buying the new Gen book, I think I'll give it a go! Thanks again for your help!!!

Hey Raja, sorry for the late reply, but I need at least a few days to read and digest your replies lol. Surprisingly, everything you're saying makes sense!  

You've definitely opened a can of worms in your patch by including a low pass filter, something I know very little about. 

filters can be set to self-oscillate, so there is some crossover(oscillation is just a stream of values oscillating within a range)... learning everything alongside everything else will always inform in the best, well-rounded way(there are medical studies that show the older people get the more they can resist certain affects of aging on the brain by learning new things that call into question what they already know, as opposed to simply building up their already established expertise on one single thing: i think some older people i've met, their mind can fall like a house of cards, you don't want to build it straight up in one column, you build a well-rounded foundation and then build from there, maybe creating more and more more branches and additions further on in life... i went off on a tangent, but it's a problem i see here on forums and on the internet in general: we want to only focus on the information we're searching for, but then we might miss so many other things that could've helped us approach that focus from a wider perspective).

but ya, try out the book, it'll go over all these things even better than i can(if i try to explain this stuff to you, i'll just end up opening you up to more questions which i won't be the best at answering) :D

Is filter design a pretty logical thing to learn alongside oscillator  design? I assume there's a lot of overlap in regards to calculus-type  functions? I guess filters are where you start running into delay lines?  Oscillators in and of themselves don't really rely too much on delay  lines, I suppose?

Gen~ Sinusoidal Oscillator is re-triggering for some reason