The “Noise (Ramped)” LFO is one of my favorite things for randomizing parameters across time.
I have questions I haven’t seen clarified elsewhere:
(1) Is there a way to show an actual waveform depiction of the LFO? It looks like it uses a “placeholder” graphic that’s scaled by the Beats/Rate, but it doesn’t depict the actual live path. There are times this doesn’t make sense, but since the “orange dot” travels without a history trail, I’m looking for a way to visualize its movement to clearer understand it across an elapsed time. This would help with events that are quieter or more subtle.
(2) Is there any workaround to add smooth/jitter to it? You may have seen this in other LFO tools like in Ableton. So for example, it’s more “gentle” as it travels back and forth with a curve, or more erratic. I would think it’d be possible to make jitter if I could stack multiple “Noise (Ramped)” LFOs with one being responsible for large-scale movements and a second being finer-tuned, but I’m not seeing a way to do that. Like, if I right-click the Depth knob there’s just Automation but not an additional Add Modulation > LFO.
(Lack of smoothing is part of why I don’t find the “Noise (Stepped)” as useful.)
If there are any other “Noise (Ramped)” tips I’d 
to know!
Hi,
You are correct that waveform depiction for a noise LFO is a placeholder - unfortunately there’s no way to show the live path, as FMOD simply doesn’t monitor or record the output history of modulators.
There’s also no smooth/jitter functionality presently. You’ve noted that it’s impossible to modulate a modulator. A simple workaround for this is to automate the modulator with a parameter that is itself being modulated.
With that said, I’ve added both of these to our feature/improvement tracker.
1 Like
Thanks for helping me. It took me a moment to mentally visualize and try out what you’re describing but OOH I think I get it now… CLEVER!!!
So I just right-click on a Parameter and it also has Add Modulation > LFO
And this workaround could scale via multiple parameters, right? Aside from some additional visual clutter if I’m adding parameters exclusively for this purpose, any other downsides to this?
This workaround can scale via multiple parameters, yes.
One other thing to keep in mind is what the property you’re modulating is a part of i.e. an event property, an instrument property, a snapshot property, etc. The behavior of a modulator is based on what it’s attached to - a modulator begins outputting a value when what it’s attached to starts, and likewise is stops when what it’s attached to stops. A parameter is always an event property, so any modulators affecting a parameter will base their behavior on the event.
There won’t be much of a functional difference for modulators with continuous behaviour like LFO or Sidechain, but if the modulator is specifically dependent on the start and/or end of whatever it’s attached to, like AHDSR or Random, then you may not get the results you want.
For example, let’s say you have a looping instrument, and you want to modulate its volume with an AHDSR modulator:
-
An AHDSR directly modulating the instrument’s volume will begin its attack each time the instrument starts, and release each time it stops, effectively applying the modulation with each loop.
-
An AHDSR modulating a parameter that you’re using to automate the instrument’s volume will only apply its attack the very first time the instrument plays (i.e. when the event starts), and only applies its release the final time the instrument stops (i.e. when the event stops).
Likewise with the Random modulator, the modulator only generates a random value on start, meaning that modulating a parameter with Random will only generate a single random value when the event starts.
Besides that and the visual clutter you mentioned, you should be fine.
1 Like
Thank you for elaborating on all of this — these tips will carry forward and help others in the future! I am now aware of “on start” behavior, but like others I’m sure, I didn’t quite get it when I started learning FMOD Studio. This is actually in part why I lean towards “LFO” more, because continuous behavior (“change across time”) is what I tend to use for longer events.