I’ve been tweaking my setup lately—experimenting with splits, layers, and sound combinations across different songs—and it got me thinking about how Cantabile handles rack saving by default, specifically the auto-saving behavior upon unloading.
Coming from a traditional file-management mindset (where a file on disk is only modified when you explicitly hit Ctrl + S), auto-saving feels a bit risky when working with Linked Racks. If you tweak a volume fader, split point, or plugin parameter on the fly while experimenting in one song, that change gets baked into the rack and automatically impacts every other song sharing it.
I recently set Save Rack on Unloading: Never in the Rack Properties, which gives me back full control: modifications stay in RAM for testing, and the file on disk only updates when I intentionally save it.
It made me curious about how the rest of the community handles this:
Do you rely on auto-save when building your live setlists, or do you set racks to Never / Manual Only?
If you leave auto-save enabled, how do you prevent unintended side effects across multiple songs using the same Linked Rack?
Do any of you use Windows “Read-Only” file attributes or other safeguards for your core gig racks?
I’d love to hear how you structure your racks to balance fast tweaking with live stability!
All my linked racks have states that I use as presets.
I usually lock all of the states in my rack and I only update them when I want to (using CNTRL+U).
In this way no unwanted change is commited to disk. I admit that the possibility of setting the update behaviour to “Never” had escaped me until now! Thank you for the heads up!
It’s really interesting to see how different users balance the convenience of auto-saving with the stability needed for live performances.
A few key takeaways from your replies that I found helpful:
Setting Save Rack on Unloading: Never (or using Read-Only attributes on core files) seems to be the preferred route for those who rely heavily on shared, complex Linked Racks.
The workflow of keeping an “editing session” separate from the “gig setup” is a great sanity check to avoid unwanted side effects during live use.
Good point on using State Behaviors selectively—disabling auto-update on specific parameters inside the rack adds a nice extra layer of defense!
Thanks again for sharing your workflows and tips. I’m new to this community (and to Cantabile, for that matter), but I’ve already realized the incredible value of this forum and the huge potential of the software. I just need some time to keep on learning! :)))
My racks all have song-specific states, which means I may have multiple states in a rack that are identical, just because different songs need the same sound. But it means if I tweak one, it’s not affecting anything else, it’s local to that song. But it also means I can make variations without adding complexity - great if I need a slight bit more reverb on a piano on one song or something.
I never use “Save rack on unloading”, so that racks reload in a reproducible state.
I don’t auto-save, but I do manually save frequently. And I have all my racks/songs/setlists in a git repository, and only commit changes there when I’m sure everything is as I want it. This also means I can undo changes in a controlled way; for example if I’m reworking how a song is set up, and it doesn’t go well, I can easily revert to the song/rack configuration I had before I made the changes. It also gives me visibility on which songs/racks have been modified when I’ve been tweaking things.
Thanks for sharing this—your approach with Git control is intriguing.
The idea of creating song-specific states within a linked rack is a great way to handle per-song tweaks without cluttering the main setup or risking side effects on other tracks.
Using Git version control for Cantabile projects is something I hadn’t considered for a live rig setup. It sounds like it has immense potential for safety and tracking changes, though I have to admit it’s a bit beyond my current IT skillset! I’ll definitely take some time to dive into it and learn how to integrate it properly.
That said, it’s reassuring to see that disabling “Save rack on unloading” and relying on intentional saving is a solid standard for live stability.
I have also gotten thinking about @Neil_Durant’s use of GIT to backup Cantabile files, as a really good idea. I myself use a cloud backup system with version history that saves changes on my DAWPC and use FreeFileSync to send changes to the GIGPC (or vice versa), but the idea of also having it under GIT version control is interesting, and both DAWPC and GIGPC could share the same GIT repository, which would make synchronisation easier.
I use GIT in my software programming, so I am familiar with it. I would say that GIT is very powerful, but can be quite arcane, so I use the built in GIT client in my IDE for software development.
You can run GIT from the command line, but that can be quite a learning curve. If you are thinking of trying it, then I would look at something like SmartGit which is a visual GIT client that is free for non commercial use. I would consider using SmartGit or similar for this task if I go this way.
Essentially
You would set up a GIT repository for your Cantabile data.
GIT will flag any changes in your Cantabile files
You can commit those changes (including adding comments for what changed)
Or you can revert changes with copies from the repository if you are not happy with the change.
Would be interesting to see what Neil uses for this: either the command line or some GIT client like SmartGit
Thanks for the great insight. It’s really helpful to get a perspective from someone who already uses Git in software development.
The idea of using a Git repository for tracking changes and synchronization sounds like a fantastic approach. Right now I’m working directly on my main live setup, so having that safety net for rollbacks is very appealing.
Also, thanks for the tip on SmartGit! Coming from a non-IT background, the command line felt a bit intimidating, so using a visual client definitely makes the whole concept much more approachable. I’ve actually timidly downloaded SourceTree recently to start figuring out how these GUI tools work, but I’ll be more than happy to check out SmartGit as well.
Curious to see what Neil’s setup looks like as well
