Save settings on Exit & Manually Saving Settings

Ideas & suggestions
1

Option: Save settings on exit

If Renoise crashes after making settings that are saved in Config.xml or KeyBindings.xml, the settings will be lost.
If you have multiple Renoise instances running, if you make important settings in Renoise instance A and then close Renoise instance B after closing Renoise instance A, those settings will be lost.
This is just an example, but I wondered if it could be solved by the following options.

  • Preferences: (checkbox) Save settings on exit
    • Default: Check
    • Uncheck the checkbox to not automatically save settings
  • Preferences: (button) Save Settings
  • Menu: File > Save Settings
  • Shortcut key: Save Settings
  • API: Save Settings

*“Save Settings” is an overwrite save to the settings file.

1 Like
2

I think this makes no sense. Renoise already is saving prefs on exit. But if it crashed, the config might be invalid and it would be not good to save it. On the other hand, it tries to save the song data while a crash. I think Renoise is quite complete here already.

Save settings manually might help indeed though, for some edge cases.

API Save Settings is not a good idea, now any plugin could force a settings save, so out of control of the user.

1 Like
3

I am writing through a translation service, so apologies if my wording is incorrect.
It is my intention to make automatic save on exit (current behavior) an option so that the operation saves the configuration only manually.
This would eliminate the need to write to the configuration file on exit and make the configuration file read-only except when writing manually, which I believe would make it more crash-resistant, more stable, and more robust.

Since I am using Renoise in a live performance environment with 4 to 8 instances running concurrently and abusing it heavily, I would like the behavior and design to be as robust and crash-resistant as possible.
With this proposal, I am offering a perspective that may be useful for such stable behavior.

Sorry if I’m wrong, but I don’t see much point in that point, since Renoise Lua allows arbitrary commands to be executed by os.execute().

https://files.renoise.com/xrnx/documentation/!%20Introduction.txt.html#h2_4

  • The Renoise Lua API also allows global File IO and external program execution (via os.execute()) which can obviously be hazardous. Please be careful with these, as you would with programming in general…
1 Like
4

Hm, yes I agree with you. Good counterpoints.

1 Like
6

@taktik Sorry for the annoying mentions.

Today, Renoise hung just before going live and when I killed it, the configuration was initialized.
This time I managed to recover by reverting from backup and setting the permissions of Config.xml and Keybindings.xml to read-only.
When the same thing happened at my last live, I could not respond in such a way. Unable to comprehend that the settings had been initialized, and almost panicking inside, I put on my “this is an artistic noise performance” face and tried to remain calm and perform an inadequate live performance. I remember that the audio settings were not correct or something and there was a huge amount of x-run.

Currently, it seems to be relatively easy to break a config like this.
Please consider this manual write feature.
I apologize if I am wrong, but this should be considerably easier to implement than trying to find a robust way to handle the configs as they are automatically written.

Renoise is pretty complete as it is, so I personally see little need to make this rich tracker more like a mediocre DAW or to include features that can be replaced by other DAWs.
In any case, I would be happy to have it more stable and robust.
(And after that, I’d be happy to see the detail usability increase as well)

I understand that this would still be very tedious and difficult, but I would appreciate your consideration.

I apologize for being rude.

7

I just closed Renoise after setting up a shortcut key and it froze, so I force-quit it and the settings for that were lost.
Since the settings were not written to the configuration file in the first place, it is not possible to use snapshots or revert from a backup.
Thus, saving settings at the same time as the exit process is likely to result in the loss of settings, so I feel it is better to do the following.

  • Settings are automatically saved to the configuration file when the relevant values are changed.
  • Option to disable automatic saving of settings
  • Add key binding settings for manual saving of settings, etc.

Please consider adding this feature.

8

As far as I know, and from some inferences, Renoise will use “memory” to store “temporary configuration” that the user has changed, both for Renoise and for the tools API.
When the user closes Renoise, both the changes in Renoise and the API changes are dumped into the respective configuration files.

The question I ask myself is, why does this have to be the case?
Why are changes not saved “on the fly” at the time of change?

These files are needed to reload Renoise or reload the respective Lua tool. It seems like something of a “safety measure” to avoid saving something you shouldn’t in the configuration files that makes the next time you load Renoise, it doesn’t return an error or malfunction.

I don’t know if there is much sense in these thoughts, but everything in Renoise about configuration is set to be saved on logout, and that data is only accessible in memory or in some temporary/staging file. If Renoise crashes, this save operation is not executed.

So there are these 2 things (speaking individually):

  • A: The save configuration file, which will be used when starting Renoise again.
  • B: The memory (or temp file or whatever it uses). This is accessible at all times by Renoise. And it has been a problem in the API in some cases, not having access to said “memory” available.

So, it’s like asking Renoise to be “smarter” with the use of the save configuration, watching everything that happens with errors.

In theory, the user should not know anything about this. He should just compose music without worrying…

There are also examples with the API. As far as I know, there is no access to “memory” for keyboard command changes. So if a user changes commands, the API cannot find out. Another example is color themes (but things are being fixed)…

From my experience, Renoise can hang if it doesn’t find a file it needs (for example, deleting a picture or icon it needs).
It’s also a bit unstable (or very slow) if the computer has multiple sound cards and while Renoise is running, the user switches sound cards (internal sound card, wireless headset, usb sound card, or the sound card of the image monitor, or something like that). For some reason it’s not agile in some cases, at least under Windows 11 (which is not the case with other sound editing software). In these cases Renoise should be rock solid. It seems like switching sound cards is a “delicate matter”, when it shouldn’t be.

There can be problems with external plugins, of course, and in many cases the problem is with the plugin.

I don’t know how it behaves with multiple instances.

But a super tracker should be able to load multiple songs in a single instance, and be able to switch between them “on the fly”. This would allow migrating data from one song to another with just one exe.

I’m just commenting on some thoughts…

9

Thank you! I appreciate it! Be sure to give it a try hope this works