Port Compatibility across Cantabile Configurations

I’m having an issue because I have various setup scenarios:

  • four different computers that can run C4,
  • four possible interfaces (RME Babyface, UCX2, UFX2 as well as Windows ASIO as a fallback),
  • four Cantabile Configurations (Setups), and
  • numerous rig designs.

I frequently change computers and rig designs (sometimes while in the car from a rehearsal to a gig) …

The issue: if a C4 song developed in one C4 Configuration (e.g. CFG-A) is opened in
another C4 Configuration (e.g. CFG-B), then any C4 routes involving a C4 port that are Enabled in CFG-A but Disabled in CFG-B will disappear in the Wiring view of the Routing diagram when I change from CFG-A to CFG-B.

In the Table View of the Routing, the route is marked as “[Port Name] (missing)”.

Things generally work out in Cantabile. When I move back from CFG-B to CFG-A, those missing routes are preserved and restored. However, I cannot work with those routes in CFG-B.

The cure: I establish the PORT COMPATIBILITY rule:

	If a Cantabile Port is Enabled in any C4 configuration,
	it is Enabled in all C4 configurations.

I Enable the Cantabile port in CFG-B, but all channels are set to (unassigned).

Instead of setting ports like this:

[MyDevice In]
  CFG-A  Analog 3/4			Input port for MyDevice.
  CFG-B  DISABLED			MyDevice not used in this configuration ... or ...
							Analog 3/4 does not exist in this configuration.

… they are set up like this:

[MyDevice In]
  CFG-A  Analog 3/4			  Input port for MyDevice.
  CFG-B  ENABLED (unassigned) MyDevice not used in this config, but
							  enabled for PORT COMPATIBILITY.

Love to hear any thoughts folks might have …
… although this situation is pretty far afield of how most Cantabile users have designed their setups …

With a C4 rig at home and the practice room, I understand your pain. My solution was to have hardware-identical DAC/ADC, MIDI IO, and USB Hubs to link them all. The computers are not the same, but the external IO hardware is the same. C4 plays well with this setup. Moving songs/sets/etc. from one laptop to the other is done with SyncToy.

I don’t use aliases, but could your problem be solved using aliases?

1 Like

Thanks @easteelreath

I’ve only used aliases for “I now have a better name for this Cantabile port” … never to have a port masquerade as another port. I don’t know what happens if Cantabile port A has an alias to Cantabile port B and you also (accidentally) have a real Cantabile Port B. Might not be pretty … and the specter of totally trashing things makes me shy away from that.

I’ve been using Dropbox with hardly any hitches … Cantabile stuff gets synched quite nicely across my machines in a few seconds. However, I need to take diligent care (on each computer) of where plugins store their presets and user presets and re-configure those plugins to use a Dropbox-shadowed folder.

Also because drive letters can be different on different computers, I’ve had to maintain Windows Junctions to make everything look the same to Cantabile (and Kontakt, and loads of other plugins and apps). Here’s one setup diagram I use to keep things straight:

When I’m monkeying with things that could have a very bad outcome, I always use Macrium Reflect to mirror the OS/Program disk so I’m absolutely sure I can return to step zero. Unfortunately, Macrium only works on computers instead of my life…

1 Like

For that, you need the One-Minute Time Machine:

https://www.youtube.com/watch?v=CXhnPLMIET0

(how’s that for an off-topic reply?)

1 Like

HA! HA! I thought for sure it would be the Galaxy Quest Omega 13 scene.

1 Like

Doing IT work for a living actually gives you that several minute time machine feeling when you run Macrium before guessing on a solution.

I have a similar problem to that described. I started on the graphical interface and find the tabular method counter intuitive. I have a number of audio interfaces and even though I keep a separate configuration for them every time I have to reassign the audio ports to the devices. Is there a way of fixing the connections for a specific audio interface and loading that as a file? Or a better way?

I think I faced the same issues as you, @anointed, and hit upon this strategy, that I only hinted at …

Each of my interfaces has a separate Cantabile Configuration (Setup). I have found that it is only a change of audio interface that, for me, warrants a change in Configuration/Setup.

So, net net, I have four Cantabile Configurations:

  • C4 WIN (Windows ASIO),
  • C4 BFP (RME Babyface Pro FS),
  • C4 UCX (RME UCX II), and
  • C4 UFX (RME UFX II).

The C4 WIN is useful for emergencies or for convenience if I don’t have an interface plugged in …

Don’t know if this helps but I’m in 2 bands and have 2 rigs (soon-to-be 3), all while playing 2 different instruments/inputs . Aliases do work, but can be tricky.

I think your last method is similar to mine…I now use the same exact port names on both rigs, but there are different channel assignments between the 2, due to interface channel count differences. I even have some duplicates where 2 different ports are assigned to the same channel, leftover from old songs I haven’t cleaned up yet. Or from differences in bands channel needs.

The key is to not copy config files. Just songs and racks and new vst’s. Example: copy from Rig A/8 ch interface and on Rig B/4 ch interface set the same port names, but manually set channels for all ports. You only need to do that once. So Port “to PA” on RigA is stereo ch 7/8, but on RigB it’s ch 4 mono, L&R both assigned to ch 4. All ports are now routed properly, no missing targets, and it is bidirectional since names are the same. Any other global config changes, which are rarely needed, are done manually on both.

There may be a better idea but with one band using backing tracks and the other not, and different footpedal commands for each band, this method allows me to take a 6 or 8ch stereo song and copy over to an old 4 ch mono backup rig, never a problem.
Ultimately I’ll have 2 exact duplicate rigs but for now it’s all good.
T

2 Likes

This is the most obvious approach and it really came into its own recently while assisting a friend with his rig via my rig. Placed the missing port names as aliases into equivalent ports of my interface and the whole rig jumped into action. This is precisely why the ‘alias’ protocol was introduced.

1 Like

Well that does clear things up and is spot on regarding the initial purpose of this thread. Thank for that!

I have only used aliases when “upgrading” the name of a port (“Oh, This port should really be called That port”) to make the upgrade smooth.

One wrinkle: When you are on the “reduced system” where the port alias names are used, won’t Cantabile change the endpoints on the routes from the Alias to the “real” port name when you save the file? If you do modifications to a song file on the reduced system, then re-open that song file on the original, full system, I’m thinking that the route endpoints will not revert back to their original ports …

At least, that’s the way I think aliases work …

As far as I can see, Cantabile is just looking for a name to work with.

Here’s the section from the Cantabile Guides that I was thinking about:

After matching to an alias name, Cantabile will rename the route to use the actual port name. Once all your sessions have been upgraded you can remove the alias name. (I added the boldface.)

It’s from this page: https://www.cantabilesoftware.com/guides/upgrading#handling-midi-device-naming

1 Like

It seems to me that removing the name is optional. A project constructed around ‘real’ names will find the ‘real’ routings if a song is loaded, even if aliases are available. If a port name is missing, the aliases solve the issue, if they have been entered. Nothing to lose keeping them.

Well, as far as I can see, that works! Thought through some of the complex cases (e.g. aliases that duplicate an existing Port on a reduced system configuration), and they seem to be OK. However, some real-world testing is in order, I think, for surprise cases.

So, maybe my PORT COMPATIBILITY rule should read:

    If a Cantabile Port is Enabled in any C4 configuration,
    then, in each other C4 configuration, it is either:
       (A) Enabled, or
       (B) Named as an alias for another port in that other configuration.

Sorry I’m late to the party, but here’s my approach to make sure my songs work across all my configurations (four different configs with different audio and MIDI interfaces):

I never name my audio or MIDI ports based on their hardware - all my ports are named by their function (Main Out, Guitar Out, Guitar PreAmp Out, Guitar In, Microphone In, VoiceLive Out, …). Then, depending on configuration, these ports get assigned to different physical outputs.

BTW: all my logical outputs are created in stereo, but for most of my live setups, I play mono, so both the left and the right channel are assigned to the same physical output - Cantabile does the mixing nicely. But should I want to play stereo some day in the future, it would simply require a re-work of the audio ports assignments - no changes to songs necessary. And in my studio, everything is set up in stereo.

The only half-exception to my “no-hardware-ports” rule is for MIDI ports: I have “logical” MIDI ports like “Main Keyboard”, “Upper Keyboard”, “Drum Pads”, and in addition I have “physical” MIDI ports (Kurzweil, MagicKeys, Motif, LaunchControl). But these hardware-based ports get mapped and re-routed to the “logical” ports within my Background Rack, so all my songs use either these logical ports or “abstracted” input racks. No “hardware” MIDI ports used directly in songs - ever!

In principle, I wouldn’t even need different configurations, as long as I use different audio interfaces (and thus audio drivers) for these setups, since the assignment is specific to the audio driver. Plug in a different audio interface, change the driver, and everything is set automatically. And Cantabile’s MIDI ports can be connected to multiple physical MIDI ports; if one isn’t currently connected, it is simply ignored.

My different configurations are used to automatically load different setlists, not to deal with audio configurations. All configurations have the same audio and MIDI ports; whenever I create a new port, I make absolutely sure it is there in all configurations. If I don’t need a port in a certain config (e.g. my guitar input and output ports in projects where I don’t play guitar), I simply don’t assign a physical port to them.

No aliases needed at all!

Cheers,

Torsten

5 Likes

Aliases are needed when that paradigm has not been followed. :slight_smile:

2 Likes

That’s my approach as well :slight_smile:

I have outputs like FOH OUT, CLICK OUT, etc.

For MIDI because I do connect to specific devices, then I do use names like To Hydrasynth, From Hydrasynth, etc., as these are very device specific and across configurations, as you say, you can assign a physical port if needed for that config.