Moog One oscillator

[cire]

Hello there,
thank you @johannes and community folks for this wonderful toy!

I'm trying to make a kind of Moog One oscillator for axoloti.
It is a mix of:
- triangle osc, with dial to change the angle into saw + or -.
- and a square osc that can be xfaded into the first triangle osc. dial for Pw should go narrow like the lfo example in the image.

I have no skill in coding, so I did something with @SirSickSik sss/osc/trisaw, (thank you Sir for all the crazy sounds!) and osc/brds/square.
Is it possible to make square pwm as narrow as the image of the lfo I put as example? does it make sense?

Moog One has oled screens for each osc, showing fixed waveforms morphing with parameter changes. I'm not shure if it shows the real waveform we hear actually, but curves look similar in my patch, except for the pw that doesn't go so thin when dial is close to zero.

Maybe someone in the community already did something close to that?
I guess it would be more cpu efficient in a single object, interesting for bigger patches with a few of these oscillators...
So,
I would use from sss/osc/trisaw: pitch, FM with sync inlet, Slope (the 1st one) with dedicated inlet.
and xfade or smux for square osc merging, with Timbre dial: pwm.
I tried to modify these objects code without success.

Let me know if anyone interested with this!

[cire]

I found something closer with @ricard oscillators, and a bit lighter on DSP load.
it is now 5% without scope, I wish I could make it twice lighter for polyphonic patches.
Any ideas welcome!

[SirSickSik]

you won't get it a lot lighter on cpu, the lightest oscillator possible will be around 3/4%, but this also means not many modulations.
Also, know that this trisaw module isn't anti-alliased, so a high pitch will generate foldover frequencies, so best use is for bass sounds.
You can easily add a low-cpu pulse-waveform (also not anti-alliased) by adding:
pulse=((int32_t)Phase>>4)>inlet_pw?(1<<27):-(1<<27);
then crossfade between the the trisaw output and the pulse.

adding fm can easily be done with the trisaw by adjusting the "phase+=freq;" part:

phase+=freq+(__SMMUL(freq,inletfm)<<8); (note that there are some "_" missing thanks to this website)

also note that I multiply the fm input with the current frequency of the oscillator. This is something that is missing in the native oscillators, but should actually be done before adding it to the freq.

Though, adding these functions will probably force it back to around 6% cpu again..

[cire]

thank you for your explanations.
I had not noticed the trisaw module isn't anti-alliased...My use would be polyphonic synth, so not so much bass.
I made another version, image in message above, that is close to it, still cpu around 5%. You're right about modulations, I guess I have to deal with it.
I wonder if there are significant changes on cpu load by coding vs patching existing modules. I suppose there is but maybe not so much?

[SirSickSik]

yes, here and there are some improvements in memory/cpu but not always noticable, sometimes it does save a lot.
Btw, not sure, but it might be that the trisaw is oversampled and filtered to prevent foldback frequencies, which also causes it to take double the cpu.

I've been working on some wavetable modules that might be more useful for this, in which case you could make a wavetable where you could mix between tri/saw/pulse. The current non-modulated oscillator only uses 3%, but as soon as wave-morphing comes into play, it's more like 5/6%, as you're basically doubling/quadrubbling(?) the oscillator and cross-fade between them. But, the nice thing is that it can have any timbre you like ánd make sure there are no high harmonics in the waveform that is selected by the pitch.
But I'm still busy on these modules as I'm making multiple wavetable generators and players that should all be able to work together and be more or less interchangable.
As for the table generators, I know have several options:
-randomly "fill" a fft-table and convert it to a waveform.
-internally generate some randomised waveform, take the fft and turn it back into a set of waves (11 variations for pitch-> 1 per octave)
-manually set the volume of each harmonic using sliders (and an option to randomise)
-take an incoming sound, create the fft and turn it to a set of waves (like nr2, but then with external input). With this one it should be pretty easy to make a tri/saw/pulse wavetable generator by just mixing and modulating the oscillators using the "wavetable-position" so each waveform has other settings.
Almost all of them have some extra controls to set the harmonic dampening factor or harmonic thinning.
Taken together with my "unused filename" module, you can create a set of wavetables pretty fast and then use these wavetables in a project using the oscillators.
But I can't yet say when I bring these out.. I made a small change in the later ones using an external array, so you could use different generators alongside each other, so I need to fix this in the earlier ones. I'll also need to make a good "demo" patch of them for generating&combining wavetables as it might be a bit difficult to understand how to make use of the inputs/controls and put it all together.

[cire]

Very interesting, especially for precise control over frequencies.
I like the randomize option, maybe possibility to assign different values to a single pot for easy morphing?
I'll keep an eye on your next modules.
For shure a help patch will...help!

[SirSickSik]

I also made a couple of extra modules like a kind of random lfo modulator and multistage envelope, which can morph from any wave to any other wave in the table (1->33->16->24->etc) alongside each stage, without the need to pass other waveforms (as in one linear morph through all the waveforms 1->2->3->4->5->etc)
The morph input just takes a normal phasor-lfo/osc and S&H the incoming wave selection when it wraps, then uses the ramp to mix from the former to the new wave. As they're all at audio rate, there is hardly any alliasing (at least haven't noticed it yet) and it sounds really clear.