I'm working on a patch that includes saving tables to the SD card using table/save, to be recalled later using table/load. I want also to be able to save certain variables along with the table, such as integers representing loop points in the table. Is there an "official" way to do this? I'm aware of the preset system, but it's not obvious to me how it can be applied here.
Saving variables to SD card while live
For saving table data to sd card you need to use table/write. And then when the data is written to table, you need to save it, by using table/save. And then load it with table/load.
Sorry, I think I wasn't clear -- I already know how to handle saving and loading of tables, but what about saving other variables, such as a single int32?
Iirc you can currently only read/write tables conveniently with ready made objects. What i would do is use a table that holds all your single variables, and then you call from that table and save/load it from sd. Worst case use a 2 entry table for single variables.
You can add a objref attribute to any object and then you have access to the referenced table within the object.
Ah, I was afraid that was going to be the solution. Is there a how-to anywhere regarding this objref technique? I don't remember coming across it in any documentation.
Something like this:
Each table read out is set to s specific slot in the table, 0 to 3 to read the data from their specific slot.
That worked, just had to hack the table/write and read objects to use integers rather than fractionals.
Reviving this old topic to ask a question: How many integers fit in a table, and what factor of a table determines the number that is stored?
A direct way of asking would be, how big would a table have to be to store 8 separate integers in it?
I'd like to be able to take that question and extrapolate it into whatever number of integers I need stored in a table. Excuse my beginner's knowledge on this, but in Jaffa's example above, there's a 32b table with a size of 16. Does that mean that you can fit 16 integers in that table, or is there a little more math involved?
Currently I only need to store a few integers, but SDRAM being of the essence at all times, I'd like to make all the space used as exact as possible. If it helps, the reason for storing integers is to save presets on objects like beat/osc/multiwave, or anything else with multiple 'modes'. Thanks!
How many integers fits in a table depends on the table size. If you set the table size to 256, 256 indexes are available to store integers in.
When you save the table content to sd-card it saves 256 indexes, if 512, 512 indexes will be saved and so on.
So if you need to store 8 integers, you would need a tablesize of 8.
Yes that means that you can store 8 integers with a value range of 32 bit. The 32 bit is the range of each value, the size is how many indexes you have available for storage.
Axoloti intentionally uses table sizes to the power of 2, cause that's what computers like the most. So you can choose between, 2, 4, 8, 16, 32, etc. size, it's the most efficient way of storing data.
For basic knowledge of how much you can load into the sd-ram, from sd-card for example, its A LOT more than you are trying to do here. To overload the sd-ram you need to load more than 8 or 16 numbers, that's very little. So based on your use case, 8 indexes, I would not be worried about sd-ram usage at all.
Okay, that's really good to know. Understood. Table size = number of individual integers stored.
So in terms of individual integers, if I'm storing an integer with a value of 0 - 255, I only have to use an 8 bit table? It's only when I need say, a number of 2 billion that I need a 32 bit table?
For basic knowledge of how much you can load into the sd-ram, from sd-card for example, its A LOT more than you are trying to do here.
Oh definitely. I'm doing the thing where I'm exceeding the SDRAM by 100 or so bytes and need to figure out how to do things as efficiently as possible so I can squeeze that reverb (or whatever else) back in there!
Thanks Jaffa!
Yeah thats probably enough. Try it out If you are storing dials in a table, you need 32 bit, but for this purpose I am sure it will work.
It takes a little while to get all this, but you seem to be on the right path. Keep at it