Analog LFO Drift Simulation

I watched a video about making digital LFO drift recently, and the results of the interesting variance and unpredictability introduced got me thinking a lot about this, and wondering if there was a simple way to make this LFO out of phase spread happen with A3.

This simple module is something I came up with to de-stabilize the digital LFOs in a patch, just like Ricky Tinez demonstrates in the video. The knob input adjusts the phase drift amount by more or less, and the trigger causes any connected LFOs (with a sync input) to then re-adjust accordingly. It works especially great for multi voiced drones! :slightly_smiling_face:

LFO Analog-izer.audulus (6.3 KB)


I made something similar a while back. Only a single channel but it has an octave, fine tune, drift amount and rate.
Screen Shot 2021-01-03 at 7.56.18 AM

1 Like

Yours looks a little less thrown together than mine, and it is probably a better implementation too :laughing:

I went through a whole lot of annoyance/frustration with my Minilogue XD to get the 4 digital LFOs to drift like the demo. It made me start wondering how I would go about making something to do it for me.

The one I made was just my brain trying to purpose build this one thing for the singular task, and I was fairly certain someone else might have already made something like this. I just didn’t want to ask until I hit a wall.

I feel like I don’t learn nearly as much when it’s not me struggling through the “how am I going to make this happen?” thought process. So I figured if I got stuck for days, and/or it seemed like something I would never solve, I would reach out. @stschoen, you were the first person on my list of people to ask if it came to that. :blush:

1 Like

The minilogue is a great synth. Every piece of gear has it’s strong points and weaker areas. For the drift the key for me was using a phasor, a random node and s&h node to generate a random value. Add a little slew limiting and you have a nice drift. I’m sure there are plenty of other ways to get the same result. It was what worked for me at the time but is certainly not the only approach.

1 Like

I went with a timer, floor multiplied by 7.99 (+ 0.01), divided by the amount designated by the knob (I think I chose 1 - 24 for the range to allow the ‘zero point’ to be actually 1 so all LFO’s could be in sync, if desired) with a clamp statement to keep it from exceeding 7.99, as I only wanted it to reset the LFOs in the patch one time. This way (how I pictured it any way), the phase drift stays constant and uninterrupted unless the user chooses to trigger a different phase drift by making an adjustment and resets the timer again. Are there any immediate holes you can see in my logic?

Since the rate at which you scan the sync pulse is very slow compared to the presumed oscillator frequency, there won’t be a direct correlation between the drift knob and the amount of phase shift for each oscillator. It depends on where in the cycle each oscillator is when the sync is received. A different setting will result in different phase shifts but the actual amount will depend on the frequency of each oscillator. It will “desync” the oscillators however which is the intent.

With your approach the oscillators will stay in tune (assuming they are running at the same frequency) but vary in phase. In my case the oscillators will drift in and out of tune over time so the phase shifts will be continuously varying. The end result in both cases will depend on the input waveforms and the number of oscillators. Destructive interference between the oscillators can result in large swings in the overall output level when the oscillators are mixed. Two oscillators with the same waveform 180 degrees out of phase result in no output when mixed. It should produce some interesting sounds though which is the point of the exercise.

1 Like

Cool, thanks for the feedback. Much like when I write utilities for the Linux and/or OS X CLI, I never assume I have accounted for everything, and always seek out a more senior engineer’s opinion, or at least have a few peers take a look at my code and discuss the intent. I feel that collaborations result in the best outcomes. Thanks for taking the time to review it! :smiley:

1 Like

You’re going to have to start writing OS XI I guess. Kinda like switching to 2021. Glad to have a look at your work, it’s always interesting to see how others approach a problem.

1 Like

That’s a good reminder. However, in this case, I actually mean OS X lol :slightly_smiling_face:

I have a personal 2020 (Intel) 13” MacBook Pro, and a company issued 2019 13” MacBook Pro. I picked up the fully stacked model for my personal because my 2015 (no upgrades) base model was really starting to show its age.

I bought the new one just a few months before the official announcement of the move to ARM chipset for the multitude of performance reasons. I don’t know that I would have done anything different if I had known, but I know what I have now and I’m not complaining :partying_face:

For the reasons of software plugin compatibility and not yet having all the kinks seemingly smoothed out for anything other than the M1 chipset, I am holding off on the upgrade.

For my work model, we are like a year behind the official Apple upgrade cycle due to all the enterprise items that can’t be on the most recent release, so we just were switched to Catalina not long ago.

My feet are firmly planted in the X world until I see substantive proof that I won’t blow up a bunch of my software/hardware compatibility due to the upgrade, like I did with Catalina (where I was very unhappy and left waiting for ~2 months for Korg to catch up and make a bunch of stuff work again):cry:

1 Like

I’m in the same situation regarding Big Sur. I have apps that I’m pretty sure won’t work, so I’m waiting to upgrade until I’m sure things are confirmed to function.

1 Like

Did you have to learn that lesson the hard way also, or did you already possess the wisdom to wait because you are a retired software engineer and you considered beforehand the implications of jumping the gun on an upgrade?

A bit of both actually. For a while I was regularly running the latest beta on my MacBook Pro and a stable release on my iMac so I had something to fall back on, but now that I’m down to one Mac I have to be a bit more careful. I’m not doing much Mac or iPad programming these days so I don’t really need to be on the latest and greatest. Many of the music related software vendors seems to be slow to support new OS releases. Sweetwater has a good guide here:

1 Like