I have, for some reason, been setting up separate configurations when I change hosts. Is that needed?
Basic question is: If I plug a different host into the same hardware (same audio interface, same MIDI and USB ports, same VSTs in the same locations, …) can I use the same C3 configuration file?
Maybe a stupid question, but: what do you refer to when you write “host”?
By “host” I mean a laptop .
I’ve got a main and a backup laptop. The laptops are different but the USB HUB, Midi-to-USB interface, and USB audio interface are the same. I used SyncToy to copy to USB Drive and move all the files back and forth from the Cantabile Folders on each laptop. So if I’m at band practice and tweak a few settings, all the changes can be overwritten to the backup laptop without an issue. I think some of the forum guys use a cloud to sync their main and backup laptops. As a rule, my music computers never connect to internet.
If you are talking about Cantabile.runtimeconfig that is located in Program Files (or anything other than the user/cantabile folder), I never touch those on either laptop. All the hardware, other than the laptops, are the same the the file syncs are flawless.
I have been using Dropbox in a similar fashion and it works beautifully. I also use filesystem junctions to handle cases where directories appear on different desks on different hosts (laptops).
My main concern here has to do with the multiple Cantabile configurations that I use. These are described in https://www.cantabilesoftware.com/guides/multiConfig
So let’s say I have three hosts (two are laptops and one is a desktop)… Call them Husky, Shiba, and Atlas (Those are their real names). And let’s say I have two audio interfaces, called UCX and Babyface. Let’s say all the VSTs and cantabile song files and Setlist are in the same locations on all three hosts (courtesy of dropbox).
Now I know I need separate C3 configurations for UCX and Babyface. My big question is: do I just need just those two configurations?… Or do I need (for some reason) six configurations: Husky-UCX, Husky-babyface, Shiba– UCX, Shiba– Babyface, Atlas-UCX, and Atlas-Babyface ???
I have so far been setting up all six configurations and it is a major hassle to keep them in step. If I needed only two of those configurations, it would be a big improvement in my set up.
Thanks for any information!
I would say that if you only use one audio interface with each computer, you can name your audio and midi ports the same on every computer and then at song level use the names. IE, in my world, I have four or five keyboards that are Main Keyboard and whichever one I plug in, either using USB or the midi port on my audio card, will always be Main Keyboard in my songs. You can do the same with audio ports. IE have a Main Output, Aux Out, Click out etc and in the ports dialogue set whichever output on the specific sound card each of those is and then your songs will work whichever combination of laptop and sound card you choose to use…
Hoping this makes sense, I’m away from the computer at the moment, can put up some screenshots of my setups if you need me to…
P
Makes perfect sense @Toaster … and gave me the idea to actually look at the files in the settings directory. I looked through settings.json and plugins.json, and neither of them seem to have have host-specific stuff (I think). There is a log file (settings.json and plugins.json … and these do have host specific info. However, they are (I think) not persistent across runs of Cantabile. It looks to me like @brad has designed all this so that the actual host-specific files are elsewhere and not part of the multi configuration setup.
However, the pid.txt file does bring up an important gotcha:
I think if you run two instances of Cantabile on two different hosts using the same configuration files (shadowed between hosts using a cloud service), you could be in hot water. I am thinking that each Cantabile instance will compete with the other to write files, on a “last one standing wins” basis, and havoc could ensue.
I am going to test the basic idea - using one configuration from alternating hosts (laptops) using the same essential file structure and the same audio interface - and (try to) avoid ever running them simultaneously (using my own common sense). I’ll report back when I have some experience with this setup.
As long as the Windows hardware names for audio and MIDI devices are the same on all three systems, you should be fine. Just be sure that the VST plugin path and your Cantabile root directory are the same on all three systems. Then everything ought to be translating OK.
I wouldn’t really sync the plugins cache or plugins.json files - better to have these based on the actual installed plugs on your system to be sure that local updates get reflected. For your use case, syncing settings.json (and the background rack) should do the job.
Cheers,
Torsten
This might be a good use for IO “Alias” names. I believe if the Alias names are the same for different hardware, Cantabile will use the same Alias name. Plus, one can have many Alias names (comma separated) and Cantabile will use that port. Pretty sure Cantabile informs you of a duplicate alias, too.
@Torsten’s answer is correct on this… so long as the audio driver and MIDI device names are the same Cantabile will find and work with them.
A couple more notes:
Regarding the pid.txt… that’s only used to recognize an unclean shutdown. You shouldn’t really sync it, but wouldn’t matter if you did (except you’d get a crash recovery on starting on the other machine… unless you’ve disabled it).
Alias names are intended for when you’ve renamed a device. If a song or rack match something to an alias name, that song/rack will be modified with the new non-alias name. ie: alias names can cause your songs/racks to become modified.
For MIDI ports your can map these to multiple MIDI devices and Cantabile will use whichever is present at the time.
For audio ports, Cantabile stores a different set of channel mappings for each audio driver - so you can configure the audio ports for each audio device and when you move between machines just manually switch the audio driver and the audio ports will use their config for that driver.
Thanks SO MUCH @Torsten and @brad for helping me along this path …
One remaining niggly is plugins.json. Torsten suggests that this should not be Dropbox(DB)-synched, and that seems reasonable given that my VSTs themselves are not DB-synched.
So it seems that there ought to be a single plugins.json per host. Is this correct?
However, plugins.json lives in the configuration directory, and it is not easy in DB to avoid synching it since my Configuration directories are all DB-synched.
Is there a way to name a single place, per host, for plugins.json? This is done in config.json for the settingsFolder parameter to Cantabile. Might there be something similar for plugins.json?
This might also be reasonably applied to plugins.user.json …
Alternately, it could be configured from within Cantabile on Options -> File Locations, as with the Background Rack location, which overrides a Background Rack in the Configuration directory. But that does seem to be a disruptively large change in Cantabile for this issue …
technically, this makes sense, but with Cantabile, the file lives in the config directory, so there are multiple. Doesn’t really hurt, since these can be automatically updated (set plugins to be scanned on startup).
Dropbox should allow you to ignore specific files, so you can just set it to ignore all the plugins.json in your config directories.
Cheers
Torsten
I’m on it!
So Dropbox is a tad clunky when it comes to UN-shadowing individual files. It’s a PowerShell command:
Set-Content -Path plugins.json -Stream com.dropbox.ignored -Value 1
(not exactly obvious …)
I’ve done that for plugins.json on three hosts for two different configurations (I have about 8 configurations in total for my different rig setups and interfaces, which is why I didn’t want to duplicate them for each host … 8 C3 configurations is a lot better than 32). Things seem to be working …
Question: What other files should this UN-shadowing be done for? I’m thinking good candidates are:
For those of us who want to automate this, there is a free tool:
Great suggestion . Thanks
DropIgnore v0.1.1 is installed and seems to be working nicely!!
One pending head-scratcher: In addition to not synching plugins.json …
Should I also not sync (i.e. ignore in Dropbox) the files: plugins.cache.json, log.txt, and log-previous.txt ??
Yes! These are specific to your local installation; plugins.cache saves information on your installed plugins, which may be different between systems (depending on how meticulously you update your plugins across systems); log.txt and log-previous.txt help you (and Brad) with diagnostics, so these should also be local.