• ### how to change the frequency of a sine wave smoothly

I'm generating a control-level sine wave to be used for LFO like this:

I'm using the multiplication box on the right to control the frequency. This works, except that it creates horrible jolts in the waveform when you select a new frequency. I can see exactly why this happens--it's jumping to a point in the phase. The question is, how can I correct it?

So far I've tried:

1. smoothing the frequency using [line]. This makes it go crazy!
2. Muting the output until the new phase catches up. This is acceptable, but I'm hoping that there is a better solution.

This has to be done at control level, not line level. Any ideas?

• Posts 16 | Views 1288
• You could try to implement a stepped low-pass in the message domain, much like a counter. I've used that with luck for exponential interpolation between random values before. Make it run on the same bang as your counter.

This is a first order low-pass filter:

y[n] = y[n-1] + a * (x[n] - y[n-1])

a being the filter coefficient (lower values = slower filter).

Try this and let me know how it works: msg-lop.pd

Also, where and how did you implement the [line] object?

• I tried putting a [line] right after the frequency number box, so that it would smooth out the multiplier before the number stream went into the [sin] object. But this had the effect of giving a series of glitches rather than one. The result is quite interesting, but definitely not what I'm looking for.

I did find a solution to the problem by focusing on the line of numbers, before it reaches the [sin] object. Basically, if you can smooth it over so that the new slope carries on where the last one left off, there will be no loss of continuity in the sine wave. Here's the solution I found: samp.pd (don't ask me how it works though).

However, this solution is so much more complicated than @LarsXI's idea of simply changing the line increment that it doesn't really make much sense. I think I'll just go with that.

• @LiamG Efficiency-wise I have no idea..... but [smooth] is an abstraction that seems closer to what you need...... smooth_test.pd than [samp]
David.

• @whale-av Here is a simple idea that could be the most efficient....... maybe........
thingy.pd
The metro can be central, and you only need the one table.....
The higher the frequency the fewer the data points within a cycle, but with a fixed metro I cannot see how you can avoid that.
You could however just add a [line] with the grain you want, taking [\$1 50( to smooth the output, but it will not be a curve.
David.

• Here's the downstream method that uses a fractional phase system! I wonder if it is more computationally intensive that just doing multiple counters, or the other methods.

downstreamphase.pd

• @LiamG have you benchmark tested the CPU consumption of 50 sine waves? Cause [osc~] is a table look-up oscillator and it shouldn't consume too much CPU. If Pd can't handle 50 table look-up oscillators, then it's probably no good.
Haven't done this benchmark test, but I'm pretty sure it shouldn't be a problem.

• @alexandros I second that, as I have built a patch with 20480 [osc~] objects, that took a while to load, but ran whilst the frequencies of every [osc~] were being constantly changed by osc messages(glissandi).
With 40960 The patch had difficulty....... and took so long to load that I never tried a number in between.
Pd extended...... so 32-bit.
David.

• Well you might be right, but my audio patches tend to run heavy already and I don't want to stress them any further. I guess that I also just like doing things in the non-signal domain. LarsXI's first solution is quite simple and effective and only uses one more object than the [snapshot~] method would, so I think I'll be going with that!

• This post is deleted!
Posts 16 | Views 1288
Internal error.

Oops! Looks like something went wrong!