I’m really struggling to understand how all of this works. Here’s what I’ve tried in the terminal:
inst_a = renoise.song().instruments[2].samples
inst_b = renoise.song().instruments[3].samples
table.insert(inst_a, inst_b[1])
Now, I’d assume that this would insert the first sample of instrument B into instrument A, right? So why doesn’t it work? When I rprint inst_a, it indeed does have a new sample, but the instrument in Renoise still only has two. What’s going on?
I can’t tell you the details of just how Renoise is managing sample objects and such, but I figured this out from the API:
-- Get an index 1 past the current number pf samples
local inst2_sample_slot = #(renoise.song().instruments[2].samples) + 1
-- Insert a blank sample object
renoise.song().instruments[2]:insert_sample_at(inst2_sample_slot)
-- get a reference to the first sample in the other instrument
local s = renoise.song().instruments[3]:sample(1)
-- Copy those details into the blank sample just created
renoise.song().instruments[2].samples[inst2_sample_slot]:copy_from(s)
My guess is that the management of samples in an instrument in a song goes beyond a basic table reference, and perhaps other structures need updating before an update to a table of samples is recognized and available.
Brilliant, that’s exactly what I was looking to do.
So far Lua is turning out to be really weird (and I’ve been programming in Python for a few years now). Thanks for your help.
Lua seems pretty transparent. Very simple core premises (lots of tables). A few things (other than indexing starts at 1, which is just evil)) struck me as quirky (coming from Ruby mainly), especially the iteration of tables. It strikes me as a better-planed, more consistent, less-weird JavaScript.
I learned a lot by looking at other people’s Renoise tools.
I think weirdness here has to do with how the Renoise internals work, because what you tried first really looks like something that should Just Work (but doesn’t).
PS.
In LUA, table.insert(table1, table2) would only insert a reference to the table - meaning that any change to the original will also be visible in this reference. This is quite important to understand, in many cases.
A simple rule of thumb: if you can display a real value with the ‘print’ function, any insertion/assignment will be an actual “copy” of the value. Otherwise, an insertion or assignment will just be a reference (to some kind of object or table).
In LUA, table.insert(table1, table2) would only insert a reference to the table - meaning that any change to the original will also be visible in this reference. This is quite important to understand, in many cases.
A simple rule of thumb: if you can display a real value with the ‘print’ function, any insertion/assignment will be an actual “copy” of the value. Otherwise, an insertion or assignment will just be a reference (to some kind of object or table).
Right. But the question is, why doesn’t this (copying references from a sample tables over to another instruments table of samples) produce a discernible effect in Renoise?
I’m really struggling to understand how all of this works. Here’s what I’ve tried in the terminal:
inst_a = renoise.song().instruments[2].samples inst_b = renoise.song().instruments[3].samples table.insert(inst_a, inst_b[1])Now, I’d assume that this would insert the first sample of instrument B into instrument A, right? So why doesn’t it work? When I rprint inst_a, it indeed does have a new sample, but the instrument in Renoise still only has two. What’s going on?
I feel like I’m late here, but I’ll try to explain what happens, as I see it.
I have not yet studied the manipulation of samples within instruments to create scripts with LUA, but I have noticed that the behavior of “how things are done” with Renoise to create scripts is very similar, regardless of what you are using.
Having said that, A new project has 10 tracks by default (0 to 9) can create up to 255 slots.I’m going to assume things now. I understand that this means that in order to add samples within the instrument number 10 or 11 (which does not exist), first it will be necessary to create an empty instrument in said slot.The same thing will happen with the samples.If you create a new empty instrument (without samples), it will be necessary first to insert an empty sample into the first slot, so that it can contain a sample. A single instrument can have hundreds of slots of samples. Using logic, I do not believe that an empty instrument (without sample slots) has a table prepared with those hundreds of empty sample slots ready to use. I suppose it will be necessary to first create the empty sample slot, and then fill it with the sample.
Therefore, to access the position of an instrument in the Renoise instrument table, you have to use .instruments [number of slot of instrument], but if an instrument does not exist, it will probably return an error. It will play to create an empty instrument first to be able to access it later.The same will happen with the samples. It will be necessary to first include the empty slot of the sample within the instrument already created.
Therefore, to access the sample you use the table instrument . Samples [number of slot of sample]
So this does not seem to make sense:
inst_a = renoise.song().instruments[2].samples inst_b = renoise.song().instruments[3].samples table.insert(inst_a, inst_b[1])
If we break it down, you are putting this:table.insert( renoise.song().instruments[2]. samples , renoise.song().instruments[3].samples[1])
"samples"you are referencing all the slots in the samples
"samples[1]"you only reference the first sample slot of the slot instrument 3.
Does the code intend to copy all instrument samples 2 into the first sample slot of instrument 3?This should not be possible.That’s why the API has this:
– Insert a blank sample object
renoise.song().instruments[2]:insert_sample_at(inst2_sample_slot)
In short, it is necessary to think that in order to insert something, first it is necessary to prepare the space where to insert it. This happens in the automation editor, in the instrument box, in the samples of each instrument, etc.
A clear example is: you can not put a sequencer track inside another group track, if the group track is not created first.I guess it’s a logical form used in many parts of Renoise.Therefore, when you save a large project with tracks, instruments and others, but without samples, the project takes up much more space than an empty project, because it is full of slots prepared everywhere, be it of points, either of instruments, or of samples…
From what I understand, moving a slot instrument is a bit heavy for Renoise. That allocation of a slot number in a table does not seem to be fast when it is changed. Possibly for this reason, Renoise does not have an option to select several instruments and drag them in the instrument box. It would be a heavy operation.
All these comments are deductions. I’m not yet familiar with the code to manipulate samples using LUA scripts.The same with phrases, DSP devices on the tracks etc.You need to create your empty slot to be able to use it,and you can only copy in it what it really can contain.
The summary is very fast. Understand what a “slot” is…
Right. But the question is, why doesn’t this (copying references from a sample tables over to another instruments table of samples) produce a discernible effect in Renoise?
Well… I look at it like this:
The syntax you are proposing could have worked just perfectly, but it would require the devs to use something akin to metatables for asserting and accepting tables/objects as an input like that. It would be a ‘special behavior’ and might not feel quite consistent with how LUA and the API usually acts. If they started adding these small inconsistencies for ‘ease of use’, they would probably add upp and eventually cause confusion and maintenance cost in the long run.
Using insert methods (like now) isn’t compromising the syntax.
From what I understand, moving a slot instrument is a bit heavy for Renoise.
The basic act of moving an instrument from one slot to another is actually quite simple and not very intensive at all.
The slowness creeps in when your song has grown a bit fat and Renoise has to search every pattern to rewrite all of the affected instrument numbers.
The more instruments, note data, and patterns you add to your song, the slower it becomes for Renoise to perform all of the necessary search/replace operations.
Try it for yourself: You can add hundreds of instuments to an empty (or almost empty) song. If there are no patterns, or even just a small handful of patterns, then moving instruments (or inserting, deleting, etc) should respond pretty much instantaneously.
Are there better ways to handle all this crap? Quite possibly, but this is just the way things are right now.
The basic act of moving an instrument from one slot to another is actually quite simple and not very intensive at all.
The slowness creeps in when your song has grown a bit fat and Renoise has to search every pattern to rewrite all of the affected instrument numbers.
The more instruments, note data, and patterns you add to your song, the slower it becomes for Renoise to perform all of the necessary search/replace operations.
Try it for yourself: You can add hundreds of instuments to an empty (or almost empty) song. If there are no patterns, or even just a small handful of patterns, then moving instruments (or inserting, deleting, etc) should respond pretty much instantaneously.
Are there better ways to handle all this crap? Quite possibly, but this is just the way things are right now.
Thanks to deepen here! To optimize to build the tools, there is nothing better than knowing exactly what happens in each moment.This is also useful for knowing what to do and what not to do when creating tools.Maybe this matter is Renoise’s Achilles heel?
The most heavy case would be to fill many tracks and up to 1000 patterns using thousands of notes from the same instrument. I have not tried it, but moving this slot instrument could suffer a lot.So, moving more than one instrument at the same time is multiplying the problem (have to rewrite the value of the instrument in each pattern when required).
Can this issue be part of the reason why there is still no classification option in the instrument box?Something like lashes, and to be able to drag several instruments from one box to another … To classification would be very practical. Even each group of instruments could include some general color, general name… I would help a lot in big projects.