The envelope. something that shows where it’s currently at, similary to the line in automation showing play/cursor position.
??
it probably me, but i have no idea what you mean ?
I’m also not sure if I get you, but there already is a line which shows the current applied pos in the envolope. Probably its just not visible in the color theme that you are using?
whoa, sorry. I meant to say “also when the song is stopped” (show where the LFO would be at that cursor pos, instead of keeping to cycle), but I guess that’s not easily possible, without tracing back to the last reset command or something like that.
If you turn off “Pattern follow” mode, the last processed position remains displayed (this is when you really mean the automation Envelope)
If you speak about the LFO device using the custom wave you can use the x6xx command to reset the starting position of the envelop inside the custom LFO envelope. No it won’t show you the last played position, but you can influence the offset.
yeah, I know…
I thought about this a bit, and think it should be possible to make the LFO be accurate when editing… but it would suck for playing notes when NOT editing, so a way to toggle it would be needed.
First let me explain what I mean, hopefully more understandable: Let’s say the LFO repeats every 40 lines. Now, when the cursor is at line 20, the LFO would be at 50% of the waveform - always. When it’s at line 30, the LFO is at 75%.
Right now it just keeps cycling, and when you press play, the LFO picks up where it was when you pressed play (which is a totally random position) — instead of where it would be when you played the song starting from the last reset command.
So yeah, that would need to be implemented first before what I initially asked for is possible.
(I’m ignoring random LFO’s for now, because unless there is repeatable randomness, it’s moot anyway… IF there was (repeatable randomness) this would prolly be very CPU intensive or even totally silly, because you’d have to regenerate the whole row of random numbers up to the point where you’re currently at in the song… or precalculate them all and store them in memory, yeah right…)
You mean that you probably would need to interpolate the reset values in the effectcommand to get a more precise position from any particular line?
No. What I mean is this.
Make a new song, insert an effect, insert an LFO, link the LFO to the effect. Now watch it move even while the song is stopped, and notice how moving the pattern edit cursor up and down, or pressing play and stop, has no effect on the LFO - it just keeps cycling. The only thing that influences it are reset commands.
To actually hear what really is going on you have to either manually insert reset commands right before the section you’re working in, or you have to start playing from the start… so if the LFO could simply hop to the point “where it would be”, similar to ReWire works, or VSTi that have step sequencers etc. that would rule.
It would rule as much as I suck at trying to explain it…
Isn’t that what our graphical envelope automation does?
LFOs always run, even when the song is stopped…
no, Johann would like a sort of “song follower” line which tells you where the LFO position would be at the current line if the song was playing.
It-Alien: yes! Well, that and Renoise automatically backtracing to the last LFO reset command and calculating the current position when you press play. Kinda like it does already for automation — and not for stuff like “x00” (“use last used value”, with volume or pitch slide for example) - there it doesn’t backtrace to the last value actually used in the song either, which would be very nice, as well, now that I think of it…
Unfortunately the only example I know of is minion/vminion, a commercial vst effect which has been discontinued… it had loads of LFO’s, and they no matter what kind of weird contraption you build with it - at point X in the song, they always were in configuration Y.
Okay, these LFO’s were hardwired to be reset at the beginning of the song… and a LFO that doesn’t have a reset command for it anywhere in the song doesn’t really have a defined state… but you wouldn’t use those in situations where my suggestion would be useful, anyway. (I for one never use any rhythmical LFO’s without reset commands before they’re used, and I don’t see why I ever would? Except for slowly warbling stuff where it doesn’t really matter, and there I wouldn’t need to see the pixelpinpoint exact position in the LFO envelope, either)
ps. I read what I just wrote, compared that to how I started the topic, and decided to kickban myself for a few days to consider my slack. I surely can do better, sorry all.
The principle of an LFO is that it is a generator that runs and is not bound to any song-running proces.
When you turn it on, it starts running. If you can manage to let it run in sync with your patternflow, then this is just how you programmed the LFO to execute it’s own internal flow.
I think in this case there are some more options necessary to trigger the LFO on more points than just one:
-Play (which it already does)
-Stop/Pauze
-Continue
In that case the LFO would be capable of doing what Johann wants:follow his moves.
But why are you not using a “fixed” envelope in such cases? I mean, thats exactly what they useful for: Play this, that value a this position, instead of cycling around all the time. Even with a custom envelope and commands to reset/set the playback of the envelope, its still an LFO. And oscillator.
Probably we need better automation drawing control if you are using a LFO instead of a real automation in first place.
And sorry for nagging, but I want to know what exactly has lead to the idea. Which problem lead to this idea.
Sorry, no… I wish you’d knew minion or vminion.
I mean, assuming constant speed (yes it gets more complicated without), the LFO position would gets set to
time since last reset command % frequency (simple modulo!)
And no, automation cannot NOT replace a bunch of stacked LFO’s that tweak each other.
I really need to make vidcap of vminion…
The principle of an LFO is oscillator is oscillation. Hardware LFO’s just dumbly cycle because that’s all they can do. They cannot backtrace on a scoresheet. That is not a feature and not musically useful, it’s because it’s a bunch of transistors and and a quartz and nothing more.
This becomes REALLY clear when you look at an actual implementation of what I’m talking about.
It’s kinda like Rewire: when you rewind to a song position, the slaves update, too. So now apply this to LFO’s (do I really need to make a video for anybody to be able to visualize this?)
If you think this is useless for LFO’s or doesn’t apply you just haven’t seen it in action yet.
The same that lead people to wanting audio tracks?
“Whenever I’m working on something near the end of a pattern/song, I don’t want to have to either play from the beginning or insert temporary commands that make stuff sound like it actually will when I render the thing”
Hey wait… recording LFO’s to automation would be sweet, and would kind of result in what I’m on about…
(well, if automation was made to have much higher resolution, that is…)
The way I understand it, the resolution of automation is the same as the actual resolution of LFO… I could be wrong though
LFO allows you to control parts in between two rows where Automation fails. Automation interpolates in between two row values, but that’s all it does. LFO is useful for fine-automation. Not having the ability to control that part in more detail is a real miss, i can imagine that.
But either we need to allow LFO to be stopped/pauzed and continued on demand or we need to enhance automation to deal with values in between rows.
We need nodes that can have a delay-offset just like we can use the delay column.
With fine-automation we can remove a limitation that the delay column currently has (because we have no pattern-zoom yet):set more automation values on the same row on different offsets.
Once pattern-zoom is there, we can seemlessly integrate pattern-zoom with automation zoom.