It’s a simple addition to the dsp::Oscillator
void changeRampTime(double rampTimeInSeconds) noexcept
{
if( sampleRate > 0 )
{
frequency.reset(sampleRate, rampTimeInSeconds);
}
}
The oscillator’s SmoothedValue member variable controlling the oscillator frequency currently has a fixed ramp time of 0.05 seconds.
Adding this will open up the door for easily adding portamento to a synth.
The alternative is to use a separate juce::SmoothedValue<> set up with the desired ramp time, and then feed the result of sv.getNextValue() to osc.setFrequency() every frame. But if you do that, you get 50ms added to your frequency smoothing that you have no choice about.
another alternative is just applying a little lowpass filter on the signal that goes out of the frequency parameter before sending it into the oscillator. i like that because it makes a nice round shape that instantly does its thing, but it’s a little edgy at the start
That doesn’t solve the problem of needing to use a separate SmoothedValue instance to have ramp times that differ from what Oscillator is hard-coded to (0.05 seconds).
why does the oscillator have an internal ramp anyway? seems to me like that should rather be part of the way midi input is handled before being given to the oscillators
it’s so you don’t get clicks/glitches when you change the oscillator frequency.
Change the speed to 0.001 and see what happens when you change osc frequency quickly and by large amounts
yeah totally. and i also understand your argument, which says that if JUCE keeps having a ramp speed within the oscillator class it should be more flexible. but my idea is to actually throw it out the oscillator class entirely, because an oscillator is not a parameter smoother, but a signal generator. the parameter values could be smoothened before going into the oscillator. then the work would be seperated better and the oscillator would be reduced more to what an oscillator is actually defined as. the objects that have the vectors of oscillators could handle that kinda stuff
ok, you should make a separate Feature Request for that.
I agree, but I guess it’s a matter of taste. I also design my dsp classes so they do what they are asked for, no matter if it would glitch or not. Any smoothing is done in the object controlling the oscillator. For me that’s a clean and nice way to work but also the reason I’m not using juce::dsp classes at all (except for juce::AudioBlock which is great).
