Settings.json change suggestion

I keep all my Cantabile songs, setlists, racks and config files in version control, so I can do controlled syncing between machines, and roll back easily when I need to. On the whole this works really well…but there’s a constant annoyance, which is that settings.json contains not only settings I’ve specified, but also transient things such as the recent songs, last song, last update check etc. Consequently such files change as soon as I run Cantabile, which complicates version management. It also worries me when I want to roll back a change I made, but there are a load of other changes in there that I didn’t make.

I used to just sync my Cantabile setups between machines via Dropbox, but sometimes got clashes caused by changes in settings.json, so this isn’t specific to version control, but possibly applies to anyone sharing configurations between machines.

I was wondering how feasible it would be to keep that transient stuff in a separate file, which just holds that kind of state that’s separate from user-specified settings?

Guessing the code changes would be impractical, weighed against the benefits…I’m aware that this is probably a very niche request, and I’m may be the only Cantabile user is affected by this…



I’m using Dropbox to sync my primary to backup (haven’t had time to check out Github) and I sometimes see the same problem. Also if I had the option I would not sync last song open, recent songs, last update. Would like to have a detailed discussion about other files that sync such as log.txt and log-previous that I should probably figure out how to exclude in Dropbox.

What would happen (negatively) if you set that file to read-only?


1 Like

I love this idea. I create periodic backups by just copying the entire Cantabile folder (with Racks, Songs, Settings, etc. subfolders) to Google Drive (previously Dropbox) but would love to use better version control. I hadn’t given it much thought, but would agree with Neil about the benefits and also the challenges of version-controlling settings.json.

1 Like

I think it is a good idea :slight_smile:

I too like this idea. Off hand I’m not sure how hard this would be to implement, but I’ll look into it.

Logged it here.


@Neil_Durant Hi, Neil. Just curious what you are using for version control. I use GIT in my software development of my Java Librarians.

My DAW and GIG PC are synced via Free File Sync, but I hadn’t thought of putting the Cantabile files under version control. But thinking about it, it is not bad idea; indeed it is a very good idea. :slight_smile:

You could have both machines pointing to the same repository, and as you say, it then gives you history of changes, so you can roll back to any baseline if needed.

PS: Hope the new IQ album is coming along nicely… :slight_smile:

Hi Derek,

I’m using Git, and pushing up to a private repository on GitHub. It was the recent move for GitHub to support free private repositories that made me finally do it, after pondering it for a while.

I previously shared my Cantabile config between three machines via Dropbox, and although it worked perfectly most of the time, I did occasionally get sync conflicts, particularly since two of those machines generally get used disconnected from the Internet, so occasionally I’d accidentally make changes on one machine when it hadn’t fully synchronised first. With Git this could still happen, but I could manage it better - easier to discard changes, stash, or merge changes if necessary.

The other nice thing is that I can commit some changes to Git at a rehearsal when I’m offline, as a safe snapshot point to return to if necessary, and push all the changes later when I’m online again.

Thanks, it’s coming along really well - almost there!!



Hi, Neil

Thanks for clarifying all that (esp the album progress :slight_smile: ).

I use Git more in a local mode in software development as my software is mostly private and I sell it. I only use GitHub for one piece of software that I collaborate on and it is free - which is CoreMIDI4J - the Java MIDI client for OS X Core MIDI (the default MIDI implementation on Java OS X still sucks when it comes to SYSEX).

But I hadn’t really thought about those recent changes that allow private repositories, so I may look into that.

Either way of doing it, the idea of putting valuable Cantabile data under version control is a might fine idea that I will look into. :slight_smile:

1 Like

Hi All,

I went through the settings json file when studying the Controller Bar feature upgrades and generated a general list of what was in there. I know Brad is looking at this but I would be interested in how other users would separate out what’s in it into discreet but linked files.

Already we have asked to detach the Control Bar section. Neil is requesting some items to be re-organized for better version control.

What else in the settings file would be better off as a discreet file for these purposes?

Thanks :grinning:



See pushing to GitHub as a safe off-site backup, or way to get your Cantabile files into another machine without needing folder shares etc…



Offsite back up is already covered via Carbonite which saves the last five copies of a file, but no harm in having another one, especially one easier to pull from another machine and unlimited depth of history. :slight_smile:

I guess with the Cantabile file structures it is easy to diff any changes?

Back OT, this is still a very good idea, especially when considered with a CM scheme.

1 Like

It’s not the easiest, partly because JSON isn’t the easiest format to diff, and partly because of all the “transient” changes in there that change even when you don’t make intentional settings changes. But it’s certainly possible to diff it - a great decision by @brad to use a human-readable format for everything in Cantabile!



Human readable formats make debugging so much easier, if you are not worried about compacting data items to binary for size efficiency :slight_smile:

Just out of interest, if you google “JSON file compare” you get quite a few hits.