Is There a Way to Run Multiple Instances of Cakewalk?

[msmcleod]

6 hours ago, norfolkmastering said:

I created two hardware profiles today and I am getting messages that they are being successfully applied.

Due to MOTU driver limitations, I only power up the audio/MIDI interfaces for the profile I want to load.

When switching between hardware profiles (which in my case means after powering down the PC and interfaces) the first loading of Sonar is extremely slow (at least 50 seconds after the SONAR splash screen appears).  After that the loading time is much faster for the same profile.

I have a couple of questions:

1. When you save a new hardware profile does it simply make a copy the AUD.INI file which was used when loading Sonar with the default profile?

2. Should I have deleted the default AUD.INI file before loading Sonar with the default profile BEFORE creating the custom profiles?

I am trying to understand why Sonar is struggling to load when changing profiles?

Depending on the options you've checked within the Backup/Restore Settings page, the config profile file can contain a compressed copy of:

• Various Sonar settings contained in the registry (it does not include your plugin inventory or anything related to your user account)
• Cakewalk.ini  (general Sonar settings)
• TTSSeq.ini  (MIDI settings)
• Aud.ini  (Audio device settings)
• ctrlsurface.dat / ctrlsurface_UWP.dat  (Control surface settings & control surface user presets)
• INSTRMAP.ini / Master.ins (instrument mappings)
• userArrangerSectionTypes.json (user arranger section types)

When applying a config profile, the existing files above are replaced with those in the config profile.  Obviously it can only replace what was stored within the file when you created it.

If you do this via the short-cut/command-line method, these files are replaced before Sonar properly starts up.  If you do it while Sonar is already running, it replaces them then re-applies all the settings from the new files.  Either of these methods should take no more than a few seconds - normally around 3-5 seconds, but certainly less than 10.

I suspect the difference in time is due to Windows reacting to your hardware being connected/re-connected rather than anything the config profiles are doing - especially since, as you say, subsequent loading of the same profile is much quicker.  Windows knows what hardware was connected the last time it was switched on, so if anything has changed, it has to deal with that.

The only other thing that could affect things would be an anti-virus/anti-malware program, but if it these were the culprit I'd expect it to be slow every time.

[norfolkmastering]

Thanks for the explanation Mark, it's really useful to better understand this stuff.

I don't want to have to use two hardware profiles but my larger hardware system (which I use when working in hybrid analogue/digital mode) uses six MOTU ultralites plus two hardware controllers,  which is pretty well on the edge of what Windows/Firewire/Sonar copes with.  It's a bit clunky!

So for composing I use a single MOTU unit which is not practical to power at the same time as the full set up (I tried, but seven Firewire connected devices was too much for Windows to cope with).  So I connect the single MOTU by USB and then only power up the MOTU units I am going to use.

The work-a-round, once the desired hardware set up is powered up, is to reboot Windows before firing up Sonar.  This seems to bring the Sonar boot-up time back down to normal (using the appropriate custom hardware profile).  This ties in with your comments about Windows remembering the previous set up.

My intention is to move to three MOTU 16As but I can't find a MIDI router to replace the MIDI ports I currently get from the ultralites.  I've tried two MIDI routers but they all seem to struggle to work in multi-client mode (which I need).  The ultralites do work okay in MIDI multi-client mode due to the Firewire interface.

Once the new Windows 11 MIDI Services release is made public (sometime in 2025) I should have a way forward with the MIDI router issue.  It promises (fingers crossed!) to offer multi-client support for any current MIDI router with Windows Class Compliant drivers.  It is also going to offer what I currently have to use MIDI-OX and loopMIDI for (MIDI routing and virtual MIDI ports).  I'm going to test all of that as soon as the public release is available.