When the Stepper is opened in the external editor, the length shown underneath the envelope is one less than the actual number of steps. The LFO’s external editor sets these as the same.
2 Likes
Disregard
OK, this is a serious issue now. The Length parameter in the external editor can push the step length to 257 and it will be used as a viable step to change the envelope. Trying to increase the Length in the actual Stepper device pushed it back down to 256, removing the step, though it can be brought back again.
1 Like
Isn’t one just starting the count from zero and the other starting the count from one? I mean, it is an inconsistency… Haven’t watched the video yet, so maybe I’m missing something.
Oh, I see, yes that could impact things
In Renoise automation there seems to be an additional step at the end, which then is the same as the first of the next automation… Maybe this bug is somehow related?
nice. so whats next, when do we finally get 258 steps?
…seriously though, could this be used to an advantage of any sort? cause i know this is a bug but like… is it a bug that can be used for anything? im just curious. or should it just be put in a cup and taken outside?
1 Like
The API knows what’s up.
1 Like
Lol and the original limit is 16 steps? So now this is the solution for when you need to crank it up some more, until you fix that bug.
Wait until you notice how the LFO reset will work - it is not going through the correct range I think, but the values are ever slightly off. I had to correct it with a formula device to get exact values for a patch where I needed it. I actually found a compensation formula that makes the LFO reset hit the exact values, it was like the step calculated was not x/num but like x/(num-1). So you can’t actually reset it to the last point or to the range from the point before it.
About the number of steps/LFO points, and the value differences I was first puzzled. Then I thought it might have come this way by intention, and that it even does make sense in some way. You see, the LFO table wraps around in cycles - the last point is exactly at the same position like the first, when you see how it cycles, I think it goes to the last and then immediately jumps to the first. So using it, you could for example make an exact saw wave cycle with an abrupt jump.
Maybe this also has to do with the difference in counting indicies in lua and c++, where you count from 1 in lua, but from 0 in c++. As a coder you can easily get mixed up with this if you have to combine both languages.
If someone fixes all these bugs in a future version, then a lot of old tunes might starting to sound a little different 
2 Likes
@OopsIFly could you please share that formula preset/code? I am working on several projects right now where I am running into this problem and have not been satisfied with my hacks to address it. Thank you.
Yes @Taktik I think there are so many bits you’re already looking to address, but fixing some of these issues with the meta devices’ behaviour would be phenomenal. I know at one time they were kind of “extras” to the software in a sense, but I think many of us make constant use of the general flexibility these tools offer, often in spite of seeming malfunctions. Thanks yous!
1 Like
Well, how you would use it depends on what you want to do with it, how you want to control it actually. Maybe you can share your preset, and will see how I can fix it up for you? In the formula, you would select a point in the LFO with the reset from 0.0 to 1.0 by using the formula “point/num” where “point” is the point you want to select, and “num” is the total number of points in the LFO graph. But this will result in an offset… Instead you need to subtract one from num, so doing “point/(num-1)”, then it will select an exact position, but you can’t select the last point this way.
Thanks. Will be fixed!
1 Like
That is indeed is cased by a bug/hack in the LFO which only can be fixed by introducing a new LFO2 device for backwards compatibility.
The LFO “claims” that it has one point point than it really has, so setting a length of 64 corresponds to one line at 64.00 LPC. Really should fix that properly at some time…
5 Likes