New tool: Live Reload for tool development

A new Renoise tool for live reloading other tools during development.

Overview

This tool adds support for building tools outside of the Renoise Tools folder with full live reloading. You can use any text editor to make changes and when you tab back to Renoise the tool will be reloaded automatically.

Usage

:warning: This tool executes arbitrary shell commands! Consider using the Renoise script editor instead if you do not understand the risks.

Download the tool from the releases page and double click to install.

In the Renoise menu go to Tools > Live Reload.

Choose the directory containing your tool. This should be the directory containing the manifest.xml.

The Live Reload window will pop up.

The “Build command” is the shell command that builds your source code into a .xrnx (zip) file. Build commands are executed from the project root folder. The command is detected automatically using the following rules:

  • If the project has a Makefile, use make
  • If the project has a exclude.list, use zip -vr ${xrnx_file} * -x@../exclude.list
  • Otherwise, use zip -vr ${xrnx_file} *

You can change the build command to anything but please be careful. It will be executed verbatim with no escaping after changing into the project’s directory. There are very minor sanity checks like ensuring you aren’t trying to zip the entire filesystem.

Press Build to force a build. If the xrnx file has changed the tool will be re-installed without prompting.

When Watch for changes is checked, tabbing back to the Renoise window from your editor will automatically rebuild the tool. Uncheck this when you are done developing!

You can close the window and builds will continue in the background. If Watch for changes is checked the next time the tool boots (which happens when any tool is reinstalled as well!) the window will be shown again so you don’t forget it’s running.

Tips & Caveats

Your tool folder must contain a manifest.xml with a valid Id set. The build command needs to create the file ${Id}.xrnx, e.g. for the manifest Id com.matta.livereload the build command should generate the file com.matta.livereload.xrnx. At the moment the generated file must be located alongside the manifest.xml in the same directory.

The tool works best when used with make. You can use this project’s own Makefile as a starting point. Make will not build a new .xrnx if the source files have not changed, which means the xrnx won’t be re-installed and the tool’s internal state wont be lost.

Installing a tool forces all tools to reload, including this one. If you aren’t sure why your tool is “resetting” that is probably why.

You won’t see an error popup if the build fails. Check the build log output instead.

Windows might work, but it might not. If it doesn’t the issue is almost certainly here. PRs are welcome.

I think leaving watch mode enabled while shutting down may prevent Renoise from exiting cleanly. I am seeing spurious crashes. Let me know if you run into this too.

Contributing

Contributions are welcome.

Please discuss new features before implementing them. I’d like to keep the scope of the tool relatively narrow.

Links

Source code: GitHub - matt-allan/renoise-livereload: Live reloading for Renoise tools
Releases: Releases · matt-allan/renoise-livereload · GitHub

2 Likes

Hello, and great tool idea! Just set up development for vscodium, and it works very well so far with makefile mode! Now I can at last use a proper IDE to make my renoise tools without much manual hassle.

Just one side note, there’s an automatic reload going each time a tool window was closed. When using makefiles this is no problem, but using zip all tools including the live reload tool would be reloaded once any tool window was closed, including the live reload tool’s window. I don’t think this is intended behavior…

That’s great, I’m glad it’s working for you!

I hadn’t noticed that issue with closing tool windows. That must be causing the window to lose focus momentarily? Maybe we can work around the issue by timing how long focus is lost for and only starting a build if it’s above a threshold.

This would also let us avoid running pointless builds when the app is momentarily focused just to close it. I’m pretty sure that’s causing random crashes ATM.