see what i mean?
the first one is done by me setting a point. (0–8)
the second one is done copied the first and pasted that one. (8–16)
after that… I wanted to use the function “paste continuously” and that is where it fails… (16–64)
Do you have a point at the end of the first looped section? I suspect you are copying 0 - 15(255) whereas the next 0 point is on 16(0). Try adding a second low point at 15(255), the difference will probably be so small you can’t hear it but your copy and pasting should work.
Although I could probably agree that Renoise should not add points you haven’t copied, assuming the end should be the same as the point before it. If it didn’t do this it would work too (with you just having to add the final point yourself.)
It looks like you didn’t copied point 16 but up to point 16 and then the end-point isn’t taken along. Since Renoise has no reference point right before point 16 (or it looks like you could also pick point 8), it assumes the last known value which is the max one.
To resolve this issue, zoom in to 1/256 mode (so you have 256 interpolation points visible and disable the lock to be able to scroll point 8 freely to the center of the automation frame) and put an extra lowest value point right before the real point 16 starts.
Then zoom out, reselect the same area you did before and then try to continues paste that.
Thanks for the more descriptive answer of what I was trying to say to him but don’t you agree Renoise should only be copying existing point and not create one of the same value as the previous at the end of the section? It should be copy and pasting data, if you copy a block in the Pattern Editor who do not get repeated notes at the end of your selection are where there were not any when you paste like this.
Jepz… I understand… but you have to admit that’s a bit laborious…
in what other situation should I use “Paste Continuously” ?
Amen!
You copy and paste a range from 0 to point x. It takes the range between those points including the start point.
the problem is, you can’t paste the endpoint across the starting point. If it would be doing it right according to expectations, the envelopes would shift one line in the automation grid at each copy and that is something you don’t want either. (it would also cause a lot of questions asked about that behavior)
You never could do such kind of copy paste action in the automation editor before so this has been frustrating for many for years. The difference is that you now have a little higher integrety field of points to lay out so you can make “Pulse” wave forms in the automation editor that you before could never make.
It may be a better idea that Renoise automatically would create this extra point on the automation time-line right before the last selected point (so you don’t have to do this manually) and simply then copy the whole automation this way, but i don’t think you can expect anything better regarding this or we should speak of going into spaces of sample-precise selections.
That might become an option in the future, but haven’t heard anyone speaking of this yet.
Although the pasting behaviour is technically correct as vV explained, I can understand how it might be a bit unexpected or frustrating sometimes. Seems like we can take a closer look at this and try to fine-tune things a bit.
I don’t see why you feel there is a need to give it an imaginary point at the end at all!
Renoise does not need start and end point in Automation!
Set Type to Linear.
Double click anywhere to get a line of automation across the whole pattern of the same value.
Although you have a line there is only one Point!
Double click somewhere else and this point will then change in a linear fashion from the first point to this new point.
Copying any of this Data should set a Start position(Flag), any Automation Points inbetween and an End Flag. As you can see Automation Points are relative to where your selection started. It should not add arbitary points which were not there originally!
Then when you Copy and Past, whether descretely or continuously, the result would be exactlty as if you had put in those points manually.
Adding a spurious value at the end (beginning also if you don’t start on a Point?) is just stupid and helps nobody. How many complaints do you think you would of had if you did that with Pattern Data? It’s all XML and can be treated just as simply!
Just downloaded the Demo to look on VERY slow work computer.
Two point automation, start and end selection slightly outside points.
<?xml version="1.0" encoding="UTF-8"?> 0,0.52439022064208984 768,0.52439022064208984 1280,0.25609755516052246 2048,0.25609755516052246 2049What that should be to Copy and Past correctly is:
<?xml version="1.0" encoding="UTF-8"?> 768,0.52439022064208984 1280,0.25609755516052246 2049Why invent a Point 0 and a Point Last/End when you already have a Length value and it’s not needed for the Automation to play?
Proof something is broken. Take the below snippet and Paste normally (Ctrl+V) in Automation Window. You see you get both points? Now Paste Continuouly (Ctrl+P) and explain to me why you suddenly have one point.
<?xml version="1.0" encoding="UTF-8"?>
<envelopeselectioncontent doc_version="0"><br>
<points><br>
<point>0,0.56097561120986938</point><br>
<point>768,0.75609755516052246</point><br>
</points><br>
<rangelength>769</rangelength><br>
</envelopeselectioncontent>
The trouble/worry comes from the RangeLength being 256X +1. This is undoubtedly done to make it so you copy the points it looks like you are copying, otherwise you might stop just before the actual point. But this does (in my opinion) need fixing. You should be copying in 256 block sections when zoomed right out, not 256 sections, plus a 1 division, then on pasting moving back a division to stop your pastes slowly slipping out of time. (Quite obvious why it was done as well.)
So to cure I would have it that you select a point (just a line on the screen) and you have selected point 0 (same as current.)
Darg to cover one division and that is points 0 - 255 (current is 0 - 256)
Etc so that your selection goes to line.255 with each selection, not includes the first point of next line like it currently does.
This may confuse people, with them finding they have to make a selection one line longer than it feels they should do. Maybe some modifications in the GUI could help this. Last line of selection being half way colourwise between selection area and non-selected or something… I don’t know but this current Line+1/256th value with an adjustment to stop continuous paste slipping out of time just seems like a badly thought out fudge-up to me.
I’ve had this same problem many times, always thought it was due to Renoise only having 1 automation point per line/tick.
First of all, apologies for the late reply to this.
This is actually the behaviour you get if you turn off snapping and then use Paste Continuously.
The problem here arises from the new snapping mode we introduced in 2.7. Traditionally in Renoise, as kazakore found, selections in the automation view have included both the start point and the end point. So when continuously pasting that without Snap enabled, you will get a slight offset for each repetition.
What happens with Snap enabled is that Renoise is trying to satisfy both the criteria of snapping to the grid and staying true to the original selection. The algorithm looks at the length of the selection and then “pads” it until the next snap point.
For example, if you select 1.5 beats worth of envelope and have the snapping set to Beats, it will do something like this:
2166 
The thinking was that you probably want the parameter to stay on the same value until the next repetition of the envelope, and not linearly rise up to the start point during the gap between the selection length and the next snap boundary.
However, if we follow this behaviour for a selection that is 257 points long, it would pad it all the way to 512 for each repetition, so here it treats it as an edge case and instead chops one point off to get the pasting to snap to 256-point boundaries.
In any case, I agree that this was probably a pretty stupid decision, as the most common use case will be snap to grid and a selection of exactly a whole number of grid sections. And if you make a shorter selection than the snap time and don’t want it to start ramping to the next repetition, you can always use the Points mode.
Also agree that it would make sense to make selections not include the last point as per kazakore’s suggestion, although that would break old behaviour that some users might have got used to.
So to fix this, I’d suggest we make the following two changes:
- Selections will not include the last point
- Snapped continuous pasting will not pad in Line Mode
Will that solve everyone’s issues here?
“Selections will not include the last point” sounds more like a “that is intended behavior” confirmation to the original complaint of this topic than as a solution or perhaps i am seeing it wrong here?
Here’s my 2 cents :
How about three different continues pasting methods of which two are toggled when triggering the continues paste a second time in a row?
The first time, it does the most intuitive expected behavior:It includes all points, but pastes the end-point at the 255/256th delay position before the actual end-position and then pastes the startposition right behind the end position where the startposition is frankly also expected. (sometimes you want a saw wave look like a saw-wave and not like some deformed pulse wave)
The second time the shortcut is pressed, it will use the old behavior. pressing the continues paste shortcuts toggles between those two modes when the snapping mode is not turned on.
The third mode is when the snapping mode is turned on, it then simply performs the snapping mode during the paste.
A different approach using the same toggle concept is adding a paste-mode button that visually shows the pasting method instead of the user having to press a shortcut twice in case he / she wants to perform the old method.
But without the button, it looks a bit cleaner
Some of vV’s points seem to make sense.
Maybe using final point in the case of a normal, Ctrl+V paste. Ignoring it with a continuous, Ctrl+P paste. The end point on the x.255 point may work in some cases too… Would probably need some real world testing to see what is most comfortable in actual usage rather than trying to work it out through thought experiments though.
In any case it should stop creating points at the start and end of selection and only copy existing points and their relative position though.