My new LFO might be over 10x faster though. For a typical usage, it may require the frequency to be a multiple of 128 samples, so if you want 6.0Hz, you might get 6.044Hz. (For common vibrato speeds, around 6Hz, it will be within about 1/20Hz of what you request.) And, it will only check only every 32 samples for a change of Frequency, Waveform, SyncIn, etc., and PhaseIn will only be checked at the start of a patch. No Duty for square/triangle. Finally, the Sine wave won't be a pure sine function, but instead, at a typical 6Hz, 214 straight segments approximating a sine wave.
In all other respects, though, the output will be as high quality as the old one, and it can support undiminished PhaseOut and SyncOut.
There will be a further optimization though. LFO's are used to adjust frequency (of an oscillator, or a filter cutoff) or volume (for tremolo), and in all these cases, you actually need an exponential curve. For instance if you want a 40 cents vibrato around a frequency f, you calculate:
f * (2^(40/1200)) ^ LFO
You can pre-calculate 2^(40/1200) to be 1.0234 (and Moselle does) but then you have to raise this number to the power of the LFO's output... EVERY SAMPLE. And raising to the power of something is slow for the CPU. So, after I get the new LFO working, I'll make the optimizer internally recognize when the LFO is being used in this fashion, and change it instead to an internal mode that outputs an exponential curve going from f/1.0234 up to f*1.0234... and we can generate that exponential curve simply with a series of multiplies instead of a series of additions. So we do away with the power calculation as well. (This optimization could be done with the current LFO, but it's so slow that the power calculation only makes it a little slower; the new LFO will be so fast that getting rid of the power calculations will suddenly be a noticeable improvement itself.)
Specifically, LFOVibrato is a module that is created for you in every patch, and is wired into the Pitch module's pitch calculation:
Output = Input * Octave * Transpose * Detune * BendRange ^ PitchBend * PitchEnv * Max( VibManual, VibControl, VibEnv ) ^ VibSource * UnisonDetune
(That's the actual Moselle default value for Pitch:Output.) VibSource defaults to LFOVibrato:Output, so we have:
Output = Input * Octave * Transpose * Detune * BendRange ^ PitchBend * PitchEnv * Max( VibManual, VibControl, VibEnv ) ^ LFOVibrato:Output * UnisonDetune
The optimizer will then change LFOVibrato's type from LFO to ExpLFO, and move Max( VibManual, VibControl, VibEnv ) to be a new input ExpRange of the ExpLFO. That leaves:
Output = Input * Octave * Transpose * Detune * BendRange ^ PitchBend * PitchEnv * LFOVibrato:Output * UnisonDetune
And LFOVibrato turns into:
[LFOVibrato]
ModType = ExpLFO
ExpRange = Max( VibManual, VibControl, VibEnv )
So, I'll make the new LFO the default LFO, and have the old one still available as "PreciseLFO" or something.
Statistics: Posted by forum — Sat Aug 25, 2018 8:28 am
]]>
I'll be picking up the projects I was working on before my hiatus, but before doing that I did some smaller fun projects.
I tried Formant Synthesis like a Yamaha FS1R, but I wasn't really happy with the results.
However I then tried Wavetable Synthesis like an old PPG or an Ensoniq (they called wavetables "transwaves") and this project worked out far better than I was expecting. Please take a look!
https://www.youtube.com/watch?v=3kxpC78CSbA
Statistics: Posted by forum — Sun Mar 04, 2018 11:06 am
]]>
While I was working on it, I've changed the Resonance parameter to be in decibels of peak. Resonance = 6 means a +6dB peak, more or less.
I did this now because I didn't want the trouble of Turbo-izing the old version, only to have to upgrade it anyway.
Statistics: Posted by forum — Fri Aug 25, 2017 8:16 pm
]]>
The Stored Waveform Oscillator (SWO) now has the ability to smoothly morph from Sawtooth to Triangle, while avoiding aliasing, just as the simple Oscillator did (albeit with aliasing).
The benefits are 1) you can make a sawtooth with just a bit less edge, 2) a triangle with a bit more richness, or 3) do similar types of things to pulse wave modulation albeit based around sawtooths instead of square waves.
I've also added a Parabolic waveform to the SWO, which is a milder Sawtooth, in the exact same way a Triangle is a milder Square. I think this should be like one of the main basic waveforms but I haven't actually seen it supported on other synths ever.
Now that I've made some long-desired improvements in the basic modules, I'll go back to the Turbo Mode (compiler) project. At the moment, it basically supports the module types: Global, Note, Channel, Voice, Patch, Tuning, and... Oscillator.
In short, I've got seven modules working under Turbo Mode, but the only one that actually makes sound. I'll be adding Filter, MultiFilter, Delay, and SWO very soon. I think there are no barriers to doing ALL the modules that do audio-frequency data right now.
I want to make further performance modifications to Envelope and LFO before I do the Turbo Mode work on them, though. (Basically, these modulation sources are currently evaluated every sample, just as audio signals are, but that is overkill. I want to change it so they can evaluate say every 8, 16, 32 samples or whatever and in the meantime simply coast at set rates. It will actually make non-Turbo Mode a lot faster as well. But it will be a big project.)
Statistics: Posted by forum — Sat Aug 19, 2017 9:23 am
]]>
The bad news is that I've come up with several great but complicated performance improvements to envelopes and especially LFOs that I want to make before I continue work on Turbo Mode. (In essence, turbo mode is so complicated that I want to absolutely finish a module and carve it in stone before further modification.)
I've also long had qualms about the Filter, which was the second or third module I wrote, back when I knew nothing about sound software
. As with LFO and Envelope, I don't want to implement Turbo Mode on the Filter then change the filter later. I need to make whatever change I make NOW, THEN continue Turbo Mode.Statistics: Posted by forum — Wed Jul 26, 2017 6:37 am
]]>
The next release will have a menu to select:
-- interpreter "normal mode" (fast load, lower polyphony)
-- compiler "turbo mode" (slower load, higher polyphony, might be buggy)
-- "turbo with quality comparison" (slowest load, but will verify that the output of both modes is the same and give you interpreter if compiler doesn't produce the same output... then it will output a time improvement.)
Also a checkbox for:
-- speed measurement
Which will give you the current performance measurement. If this is off, patches load about a second quicker.
Statistics: Posted by forum — Wed Jul 19, 2017 3:56 am
]]>
]]>
]]>
]]>
The long version:
Alpha #10 is basically turning Moselle from an "interpreter" into a "compiler." Up until now, Moselle was slow because Moselle itself is always running, figuring out what your patch should output next. In the next release Moselle is turning the patch into something the computer itself can run, then turning control over to that and letting it work. You can picture an "interpreter" as controlling an industrial robot with a joystick, while you read an instruction for what it's supposed to do. The "compiler" in effect teaches the robot to do the job itself and it can do it much faster than you could.
So: yesterday and today I finally got compilation working! Except not really. No matter what your patch is, the result is as if it was just a one-osc voice playing a sinewave. So: proof of concept is done. And it's twice as fast (twice the polyphony) as before.
Tonight I've done most of the coding for getting the first module type (Oscillator) to actually compile. I have some other subprojects that need to be done (eg, compiling formulas) but it's moving along. I can't quite see the entire solution in my head, but right now it looks, well, a lot easier than I was expecting.
Statistics: Posted by forum — Tue Jun 20, 2017 6:10 pm
]]>
-- patches you write with Alpha-09 will work forever,
-- the output of the patches will not change at all.
This meant all changes to the way the existing modules work would be finished. All changes to the language would be done now. Future changes to the modules and the language would add new features, new modules, etc., but not change any detail of existing modules.
However I am not going to meet this goal. I only have a half-dozen projects left to meet this goal but I just want to release it as is.
There were several other things I hoped to do: improvements to the 260+ tutorial files, and improvements to the GUI. However these I can frankly make any time. Making them later, even much later, won't impact whether patches continue to work or sound the same.
So the good news is, probably, Alpha-09 release tomorrow.
Statistics: Posted by forum — Fri Jun 09, 2017 7:07 pm
]]>
-- patches you write with Alpha-09 will work forever,
-- the output of the patches will not change at all.
This meant all changes to the way the existing modules work would be finished. All changes to the language would be done now. Future changes to the modules and the language would add new features, new modules, etc., but not change any detail of existing modules.
However I am not going to meet this goal. I only have a half-dozen projects left to meet this goal but I just want to release it as is.
There were several other things I hoped to do: improvements to the 260+ tutorial files, and improvements to the GUI. However these I can frankly make any time. Making them later, even much later, won't impact whether patches continue to work or sound the same.
So the good news is, probably, Alpha-09 release tomorrow.
Statistics: Posted by forum — Fri Jun 09, 2017 7:07 pm
]]>
The modification of Moselle only took 15 minutes. Then modifying about 500 patches I ship with Moselle, that are generated by a script from some other data, only took a couple hours. But I've spent two days now trudging through all the other demo and example patches. Basically, if they had a gain envelope, I'm renaming that to EnvGain, at which point the sound will be identical to before.
Most of the rest of the patches just automatically start using EnvGain to cut out key-click. That is great, but then the automated test procedure, which compares the output of every patch to reference copies, reports that the sound is no longer the same. Of course it's not the same--I've eliminated key click!--but the automated test doesn't know WHAT is different, which means I don't know if it even works any more. So I have to test 200+ patches by hand.
While doing so I found a tricky bug in the envelope. There was one line of code that I've had to "fix" 3-4 times before, and of course it turns out I wasn't fixing it, I was instead making it work for SOME patches while making it NOT work for some OTHER patches. I spent 45 minutes really studying this one line of code and realizing that "one size doesn't fit all." That line needed to do very different things in different kinds of envelopes. The Envelope now figures out which of two cases your envelope falls into and does the right thing for that kind of envelope.
Today I'm just too tired of testing patches, so I've been working on the actual manual. (Yes, there is a manual, about 123 pages so far!)
Statistics: Posted by forum — Mon May 22, 2017 7:15 pm
]]>
An example of what is too small to even mention by name: renaming some variables of some modules so they kind of fit into a larger scheme.
An example of what I might put off: making the MIDI timing clock usable inside a patch, which would actually be a great feature but a lot of work for its comparatively limited appeal. And I can always do that after production releases are available. The key thing to do now is the CHANGES to functionality, not the NEW functionality. This is because changes to functionality make existing patches stop working, which would be a disaster once there's a large user community. In contrast new functionality can be rolled out after there are lots of users as it doesn't have any negative impact.
Statistics: Posted by forum — Fri May 05, 2017 9:44 am
]]>
An example of what is too small to even mention by name: renaming some variables of some modules so they kind of fit into a larger scheme.
An example of what I might put off: making the MIDI timing clock usable inside a patch, which would actually be a great feature but a lot of work for its comparatively limited appeal. And I can always do that after production releases are available. The key thing to do now is the CHANGES to functionality, not the NEW functionality. This is because changes to functionality make existing patches stop working, which would be a disaster once there's a large user community. In contrast new functionality can be rolled out after there are lots of users as it doesn't have any negative impact.
Statistics: Posted by forum — Fri May 05, 2017 9:44 am
]]>