Copy/paste inside one track in realtime

Renoise Tool Development
1

Is it possible to copy whole track in pattern to string and then partially copy back few lines at once?

2

The question is a bit unclear.

You cannot paste a range. You can only set property by property in renoise.song(). Unless you want to make a direct copy/paste from one pattern/track/line to another. Then you can use the fast :copy_from methods, where available.

Or are we talking about caching pattern data in some sensible structure, and reusing/pasting whatever later on?

3

A kind of track buffer created in playmode every time in the beginning of pattern so that data from this buffer could be written back to track at current play position when button pressed.

4

(I’m assuming that you don’t just want to do a straight up copy/paste of a line, but also need to manipulate the data before pasting? Otherwise the :copy_from methods would be the quickest for 1:1 copying.)

The Renoise objects (patterns, tracks, lines…) cannot be created in the LUA environment, so you cannot reuse these classes in hopes of using the fast :copy_from methods, for example. You will have to create your own scheme and structure to copy/paste from.

If you need the absolutely quickest way to extract pattern data, I think you should iterate renoise.song().patterns[].tracks[]:lines_in_range(index_from, index_to) and dump the line strings to a table. index_from being 1 and index_to being max_number_of_lines. Then using string functions to extract the data as “normal” line properties.

However, you could start simple for now and just make a simple table-structured representation of pattern->track->line and optimize it per above if needed.

5

(I’m assuming that you don’t just want to do a straight up copy/paste of a line, but also need to manipulate the data before pasting?

Not related to strings but just in case it this can help with brainstorming: You can cheat by creating a new temporary pattern, manipulate the data there, then put it back. For example, in Grid Pie, all the work is done in a temp pattern named GRID_PIE appended at the end of the track [1]

6

I wasn’t going to manipulate data, just wanted to be able to copy for example from lines 1-8 to 9-16 of the same track and pattern in play mode. Well, I guess i’ll do it line by line

7

So, this stores only references, right?

lineBuf = {}
	
	for l = 1, lines do
		lineBuf[l] = song.selected_pattern.tracks[trackId].lines[l]
	end

This stores values:

lineBuf[l] = tostring(song.selected_pattern.tracks[trackId].lines[l])

And how to write back line strings? This doesn’t work:

song.selected_pattern.tracks[trackId].lines[la] = lineBuf[lb]
8

So, this stores only references, right?

Right, since lines[1] is an object.

Bluntly explained, a simple “rule” is that anything that can be seen with print() will copy the value on assignment - but anything that requires rprint/oprint to print anything meaningful will just be a reference.

And how to write back line strings? This doesn’t work:

Assuming that you need to store the line data for later use, and that a realtime 1:1 copy is not sufficient:

You will have to make your very own scheme for this. I think that you have two good options:

  1. Make your own “line class” with copy_from and copy_to methods that will store/restore all relevant values. This will provide a simple and straight forward syntax once the class has been made.

My proposition, due to being much faster with less overhead:
2) Store the line string. Make a restore_line_string(string, destination_line) function to paste the line string to a line object - extracting/pasting value by value by using string functions. The fetching of the line will be much faster than the solution above.

Do note: if it’s sufficient to copy one line to another (without any ‘caching’), you should use the :copy_from() method in the renoise line class. This should be super fast compared to both of the above methods - hence Conner_BW’s suggestion of using a “tool pattern” as caching place. (I am principally against modifying song data like that. It’s kind of a hack.)

9

I am principally against modifying song data like that. It’s kind of a hack

I too thought that it is not pretty solution, but then again, why not? Maybe I should reserve buffer pattern that is changeable in tool’s settings.

10

Theoretically, it could interfere with the function of other tools - and it will potentially bang a couple of notifiers on the way.

Still, I’d suggest starting with the simplest solutions, as the project is pretty big :slight_smile: It can always be fixed later on.