Don’t use single cycle feature?
Will this work so that if I put a single cycle switch-on into pattern LFO cycles through current cycle and stops?
Use the first LFO to modulate the filter, and the second, custom-shaped LFO to modulate the offset of the first one. Reset the second LFO instead of the first 
That sucks 
Seriously. Are LFOs in one-shot INTENDED to stop broadcasting after a cycle?
I really think so
If you think about it it’s actually the more flexible option… you can always have 2 LFOs if you want to have the one-shot + continous modulation package… Then again I guess you could toggle the first LFO’s bypass on/off if it was the other way around…
Well… Not to be a dick about it. But what this sort of means is that one-shot LFO’s can’t effecticely work together. A huge benefit of LFO devices is chaining them to modulate offset and frequency with other LFOs, and the way this works now you can’t have a one-shot LFO intuitively modulated over time by a regular LFO.
Honestly, as much as i’ve been crying about wanting this, if a technical limitation of how the LFO is implemented means it can’t repeat broadcast the final value indefinitely when in one-shot mode, i’d actually rather this functionality be removed from 2.0 until it CAN be implemented “properly”.
To be more precise; LFO’s ALWAYS continuously broadcast, ever since the first iteration. This is how the device has always worked, and that functionality is a part of our psyche when we work with it. I don’t believe in “soft” rules for software UI. If this version of one-shot was in an application i wrote, i’d cut it from the final release or do it differently.
An LFOdevice that doesn’t continuously broadcast is inconsistent behavior.
An LFOdevice that can’t be chained with another LFOdevice that happens to be in a certain “mode” is inconsistent behavior.
As much as it pains me to say this, i’d rather not have a one-shot mode then. I think it dilutes the device if it changes the behavior this much. It breaks the “language” of the Renoise UI.
If there are plans for a generic envelope device that works like the current one-shot LFO device, then hooray. Let’s cut one-shot from the LFO and make a proper envelopedevice. If not? Argh. This is hard.
^ i really like this feature.
though i agree with your points…(just not that it should be removed) multi out lfo, controlling a lfo with a lfo and stuff like that would be really handy. but its not like you can’t do what you want right now, all you need to do is use more (custom) lfo’s and put in the triggers yourself. (i know… sounds like work ;] , but you can. )
also i would love to be able to select the custom lfo presets by code/drawn automaton
Yips. Actually it was more work to stop broadcasting than to continue broadcasting. I simply thought its more useful the way it is now. I dont really care to change this if thats fine for others as well…
Well it’s not about sustaining the last point of the LFO, so much as it is being able to still animate the offset and have that affect the output even though the one-shot has finished it’s run.
Is it possible to broadcast updates whenever the offset is changed? Automating the frequency and amplitude has no value once the envelope has stopped playing, but the offset still has value.
For a clear example, make a Filter3, an LFO, and hook the LFO into the cutoff. Set the amplitude to 0, and move the offset slider. In this way, even if you have a static oscillation, you can still use the offset to modulate the target parameter. This is a crucial feature of the LFO imho.
Picture a scenario where you have a slow LFO driving a resonant lowpass on a bassline. At SOME points you want the filter to do a “skip” to let more highend through, let’s say you want something like a syncopating bassline with your kickdrum or something. Putting a one-shot lfo between the slow LFO and the filter, with the slow LFO driving the offset of the one-shot, you could basically have a solution where one LFO simply lets the modulation from the other through untouched, until reset/triggered by commands.
To me, this is a hugely powerful feature, and a big deal of why i was excited about the idea of a one-shot LFO in the first place.
Here’s a better example.
http://www.doomsday.no/misc/lfo.zip
Filter3->oneshot LFO->LFO
pattern 1 drives the oneshot with 0 amplitude. The value from LFO2 is passed through.
pattern 2 applies 50% amplitude to the oneshot, the two values multiply
pattern 3 only occationally triggers the oneshot. Values from LFO2 are lost.
I dunno how much clearer i can make my view on this. I already feel like a big whiner. Personally, the behavior as it is feels really buggy and limiting, and i’m having trouble figuring out places i even have uses for one-shot LFOs without the ability to drive their offset effectively.
Done now. The LFO will now continue broadcasting, even when having reached the end of the one-shot…
But: Wouldn’t this be more flexible by adding a loop to the custom envelope?
Taktik. I could kiss you.
If you could add a loop to the envelope it would be amazing 
Isn’t that a GUI real estate problem though?
Not to be an ass myself, but did you even try my suggestion? Maybe I’m simply unable to comprehend what you mean…
Anyways, you wrote:
This is possible with the LFO as it is now. You just let the one shot modulate the offset of the slow LFO instead of the other way around. Put the amplitude of the 1-shot to 100% and you can decide where exactly you want the offset of slow-LFO to end up.
Again, sorry if I’m totally missing the point here…
It’s really not so much about wether you can somehow make something work, as much as it is about not changing how people expect the LFOdevice to work in different contexts.
The LFOdevice with oneshot, as was, was a great addition to the device. I felt that if the team would ship 2.0 with it in that condition, it would break some ingrained idiosyncracies of the device and possibly collide with past workflow.
To ask it differently, do you think making a one-shot LFO sustain the last value makes it worse? If so, why?
I didn’t find the original behaviour all that odd I guess, but to be correct it was – as you said – more similar to an envelope than a LFO. Nevertheless, the custom LFO’s shape is transient and I would find it more obstructive if it potentially interfered with pattern commands after it’s run through.
Maybe an envelope generator would simply be more logical overall than the LFO device, since it would be able to do the same work and then some (if it includes loops and sustain-levels such as the one in the instrument editor)
I really agree that a dedicated envelope device would be the best solution, with loop sections like Taktik says.
As an option slash workaround until the team has time to build a proper envelope device, it’s about weighing the pros/cons of a feature. To me the pros of a one-shot mode are outweighed by the cons of the feature causing inconsistent behavior.
As for the device interfering with pattern commands, LFO’s have ALWAYS done that. That’s part of the bargain. If you want it to stop affecting the track, simply shut it off until you want it again.
Well, what should an envelope device do what the custom LFO one-shot mode not does? A Loop can be added to the LFO Device as well. We wont add a new device just to configure the “continue broadcasting” behavior, don’t we?
Well technically it wouldn’t do anything other than ease the bloat of the LFOdevice 
The way the device is changing now you could almost rename it to modulationdevice. It’s like a swiss army knife of automation.
Sorry to drag up an old topic. At the time this was all posted I didn’t have a problem which ever way the one shot lfo worked. However, tonight I’ve run into a problem with the current implementation.
I want to have a series of one shot lfo’s all modulating a filter3 cut off, with the idea being that I can trigger any of them in turn individually and vary the orders/numbers of repeats/etc of each one-shot as my song progresses.
The problem is that since the lfo’s continue to broadcast at the end of their one-shot, the final lfo in my chain holds the filter3 cutoff at a fixed value and none of the other lfo’s can change it when they are triggered.
Maybe I could solve this with some combination of turning lfo’s on/off when triggering them, but it would seem impractical to simultaneously turn 1 lfo on, trigger it and make sure another 5 are off.
The best solution would be the loop feature taktic suggested above. Sunjammer could loop the final section so that broadcasting continues, whilst I could have no loop so that each individual lfo has an effect when triggered.
Any thoughts?
yes pleaeaeaeaeaeaeaeaeaeaeaease … 
donut on a glass plate
Any body else care about this? The more I’ve tried to work around it the more convinced I become that this is an issue. The previous “one shot keeps broadcasting” fix solved sunjammers problem, but breaks them for my purposes… Is it really just me?