Problem moving automation curve points


See video. When you try to move the curve point, the cursor immediately zaps to the automation point. So you end up moving the automation point instead of the curve point.

It seems you have to click the utmost left pixel of the curve point to grab it.

This problem is also present in the regular Automation Editor. When you hover over a curve point, the cursor icon will transform into the double up-and-down-arrow which indicates that you will grab the curve point. But often, you will move a nearby automation point instead.

Makes sense?

1 Like

Renoise version?

i could not replicate the issue

also the lfo:

You have to add more points to the grid, 3 isn’t enough apparently.

You can if you change the grid points from 64 to 3.

Renoise 3.3.2, Windows 10.
You can experience a somewhat similar behavior in the Automation Editor when the curve point is close to an automation point. See video.
Though the cursor icon changes to the double up-down arrow, you often end up moving an automation point when there’s one present nearby.

In fact, you can also replicate it with 64 or any other number of lines in the LFO. You just have to make two automation with one line of distance between them (say a point on line 31 and 32) and then move the curve point between the two automation points all the way up or down. Then it will happen.

Yes, there’s nothing to interpolate and thus scale in this case. I guess we should avoid showing those curve guys then to avoid confusion.


yup, i can replicate now both in automation, modulation, in lfo editor. Thanks for describing exact steps.

But the LFO curve points are still working their magic (which I like!). It’s just that the graphical representation of the envelope is missing. See example song. The difference between the modulation of the volume and panning sliders is all due to the curve guys.
LFO curve thing.xrns (3.9 KB)

1 Like

I just noticed this as well, it actually works, it’s just the graphics that’s not displaying it.

In fact, this is also kind of the case in the Automation Editor. The curves are graphically represented as linear lines (see max zoomed in image below). And they are also manipulating the parameters like that.

But in the Automation Editor you have 1/256 lines of resolution , while there’s only 1 line of resolution in the LFO Envelope Editor. Graphically, that is. The processing resolution seems the same (1/256 of a line, I would think).

The other difference is that the lines don’t always go through the curve point when there’s a short distance between the automation points. That’s pretty noticible when there’s only one line between the LFO envelope points.

Nothing of this bother me, though. Most important thing is that the LFO is processing in curve-like fashion. Also for backwards compatibility. Of course, it would also be nice if the problem this thread originally was about - moving the curve points - is fixed. But in most cases, you can work your way around it.

Sorry for the late reply and thanks for the detailed report. Yes, this will be fixed in the next maintenance update.

1 Like

Great!!! If the fix also took care of the related issue in the Automation Editor, it would be perfect. The issue is this:

  1. When you hover over a curve point, the cursor changes to the double up-and-down-arrow and the curve point thickens (the little white square becomes bigger), both signalling that you are about to grap that curve point. That’s all good.
  2. But you (well, I) often end up moving a nearby automation point instead. (see gif below)

It would be great if the cursor only changed to the double arrow when you are in fact about to grap the curve point.

I do a lot of micro level automation, so this happens quite frequently for me. Might not be a problem for others. In any case: Glad to hear the LFO thing will be fixed!


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.