Preferences.xml - some no0b questions

I am making a track template tool (including dsp chain and column settings et c) and for the first time I will use the scriptingtoolpreferences system more extensively. Maybe someone could help me get an easier start by giving some advice.

  1. I am trying to store a value of “1” as a variable in the preferences, but in the preference file it gets stored and loaded as “1.0”. Am I making some mistake here?

  2. My XML will contain nested arrays. Would it suffice to handle the preferences by the simplest way possible of reading and writing to arrays, or would I need to do it in an OO fashion and with methods?

The float/int thing should not make a difference in most cases, I would think. Not sure what your usage is, or if you are planning to do math on it, but otherwise you’ll be fine.

Nested arrays is not possible, sadly. I’ve written a slightly sad and angry post about this some time ago. I said it’s especially sad because XML is such a great format to easily save these nested things. If I’m not mistaken you will have to write your own serialise function, in the way that mysql allows you to query for the structure of a table such that you can instantly use that as a ‘create table’ statement.

It does seem to matter. When storing the value of track().volumn_column_visible, it will be saved as 1.0. When read this needs to be read as 1. I guess I will have to make exceptions for every parameter that requires so.

Thanks! I will have to check some tool that uses the method/document approach then. My problem is that I am not too familiar with the syntax of ‘object orientation’, so I probably won’t understand fully what is going on even if I get it working :)

Lua’s internal representation of a number, any number, is a double precision floating point number. So numbers will get stored as doubles in Renoise’s Lua API XML exports too. If you save a value of 1, a value of (exactly) 1 will be restored too.

See http://www.lua.org/pil/2.3.html why (or better said why not) Lua uses doubles as numbers.

Well, what you might find help in is Overtune. It saves settings tables to a string in a way that allows you to recreate the full table again as a lua object by simply using loadstring() (that’s a ‘eval’ kind of function, pass a string and execute). Although I haven’t tried it, I’m confident you can successfully save these types of strings into the prefs like you would any other.
Here’s a link to the code: main.lua - see lines 340 through 366 for the saving and loading mechanism (the functions are called try_and_save_2 and try_and_load_2, for backward compatibility with older overtune instruments.)
For the saving, you can think of it leaving out the "Overtune !! " part at the start, it’s just for recognising OT instruments. See the concatenation of strings in these lines as writing down, to a string, exactly how you would write it down in lua ‘hardcoded’.
Then with loading, really you only need to pay attention to the line 345 with the loadstring call. You can read up on loadstring here if you need.
Hope this helps!

Thanks. It looks a bit hackish though, so I’m trying the general OO approach.

It’s very unclear to me how this works, even after reading the docs. Exactly when do preferences get saved and loaded?

I am using self:add_property(“param”, value) in my class function. I understand this as needed for ‘registering’ what parameters are available to access them later. However, this initialization will overwrite the content of preferences.xml. Could anyone give me just a small hint on what approach to use?

Heres a small modified snippet modified from a recent tool of mine, maybe it helps? it shows how to set individual values in the preferences. You can then use them in the script by calling with the fullpath`:

options.foo.value

where foo is any name you choose.

  
-create preferences xml  
local options = renoise.Document.create {  
 preserve_column_pos = true  
}  
  
  
--assign options-object to .preferences so renoise knows to load and update it with the tool  
renoise.tool().preferences = options  
  
  
--print value --> true  
print(options.preserve_column_pos.value)  
  
  
--reset value to false   
options.preserve_column_pos.value = false  
  
--print value --> false  
print(options.preserve_column_pos.value)  

edit:
How the preferences XML appears when preserve_column_pos is equal to true :

<?xml version="1.0" encoding="UTF-8"?>  
<scriptingtoolpreferences doc_version="0"><br>
  <preserve_column_pos>true</preserve_column_pos><br>
</scriptingtoolpreferences>  

Thanks, Ledger. I’m with you this far, but what happens next time you start Renoise? As far as I can see, preserve_column_pos will get set to true, even though it was saved as false last time?

no, this will be checked for behind the scenes by renoise, so it is only created/ defined when it doesn`t already exist.

Ok. Thanks a lot, I’m very glad to get this confirmed. I’m probably doing some other mistake but I’ll sort it out!

If yourre still having probs, post a snippet up here and if I cant help I`m sure someone else can.

Anywhere else in the script, the options should be saved as soon as you alter a value (remember to change its .value!!). You might again see how it’s handled in the overtune script looking up the places the ‘options’ var is called. I’m curious what you come up with for saving nested arrays!