Cakewalk’s CTO Noel Borthwick has been hard at work creating this microscopic view of SONAR 8.5 for those of you who have expressed an interest in learning more about the internals of the new features. Throughout this post, Noel will uncover the new version from an engineering perspective. However, before we get started on the fine print, let’s first clarify some facts and myths about SONAR 8.5.
What’s in a name?”
What’s in a name? That which we call SONAR 9 by any other name would sound as sweet.” I guess Juliet was misinformed, based on the wild speculation and reaction to our announcement of SONAR 8.5. To ease the anxiety for the next release I will let you in on a secret – the next product release will be called: SONAR 1C21B83D-EDCE-41b7-BBEF-31F912E88B1D. We think that a 128 bit version number will dispel all ambiguity the next time around.
FACT:
• The .5 release name for a major product reflects a change in our internal nomenclature for naming products, a business decision that was made after careful deliberation.
• Going forward this more accurately reflects our strategy of shipping products with high value for customers, while simultaneously planning for certain types of features whose depth may require a longer timeframe to develop and integrate.
• The 8.5 name is also indicative of the fact that 8.5 is available as an downloadable upgrade. i.e. unlike earlier versions it can upgrade an existing SONAR 8 install.
• Don’t be confused by the .5 in the name. 8.5 IS the next version of SONAR – It installs as a brand new version and lives alongside your existing SONAR 8 version just like any prior full release of SONAR.
• You can also simultaneously use 8.5 or an earlier 8.0 version just like any earlier full release of SONAR.
• If you purchased SONAR 8.5 as a downloadable upgrade, you must have SONAR 8 installed prior to installing SONAR 8.5. To reduce download size, the package doesn’t include all the content that you already have in your SONAR 8 install.
• You can also purchase a full set of 8.5 DVD’s even if you bought the download from our web store.
• If you bought the retail version of 8.5 from a store you already have the full 8.5 DVD set with all the content.
• There is no difference between an 8.0 install upgraded to 8.5 and a full retail 8.5 box install
• The depth of the new features and enhancements in 8.5 actually exceed what went into SONAR 8 coming from SONAR 7.
FICTION:
• The main SONAR 9 release was postponed and SONAR 8.5 is a patch or hotfix. Wrong – our maintenance releases are for compatibility and improvements only with the occasional bonus feature thrown in. We never add full blown features.
• A new version of SONAR is around the corner and 8.5 is an interim release. Wrong – We’re good, but not THAT good to be able to deliver a full new product just after shipping this one. Thanks for the compliment though!
So let’s cut to the chase shall we? There are several classes of new features in SONAR 8.5. I will try and focus on the pieces that are not covered in our marketing copy since by now you are already familiar with most of that.
You can read more about SONAR 8.5’s big features here if you are still catching up.
Disclaimer: The information below may be subject to errors and is not intended to be an exhaustive list of 8.5 features. It may be edited from time to time. You have been warned – nauseatingly geeky details follow. Stop reading now if this is objectionable to you 🙂
Like the predecessor to SONAR 8.5, one of the themes we pursued was Optimization. This time around in addition to general processor level optimization, a few specific engine areas were additionally targeted as broken out below:
General Code Optimizations
Some general areas that were targeted for optimization in 8.5:
• Common 64 bit audio conversion routines are now faster – the effect of this can be observed when streaming audio in double precision mode.
• Further reduction of system call rates and reduced kernel use – allows for more driver bandwidth
• Reducing/optimizing locks and removing known bottlenecks in the low latency code path.
• Switched to the latest compiler tools for this release. This buys us some small gains due to Microsoft’s compiler level optimizations.
Throughout the 8.5 cycle we worked closely with Intel getting feedback on our performance improvements. Intel engineers had access to early alpha and beta builds and reported back on specific workloads and tests we requested them to compare performance with. The result of this hard work is superior performance with the Core I7 family of processors. In recognition of Cakewalk’s work on their platform, Intel showcased Cakewalk at this year’s IDF. Carl did a presentation on Cakewalk’s timeline of support for the Intel platform and Brandon did a kickass demo of SONAR in front of an audience of nearly 3000 including top Intel execs and industry personnel. Great mindshare for the advancements made in SONAR.
SONAR was running:
• 140 tracks
• 24 simultaneous live virtual instruments
• 50 simultaneous live audio effects
• An 800 MB high def AVI video
• And Brandon played live at 2 ms of latency
• All at only 50% CPU
You can learn more about Cakewalk at IDF 2009 here.
*The net accomplishment of all this work is even better low latency audio playback especially on the 64 bit platform. Note that most of these optimizations are generic and apply to AMD systems as well.
Auto Priority Inversion Detection
Priority inversion is something that most highly multithreaded applications run into at one time or another. In the case of an audio application one common symptom when this happens is audio stuttering a.k.a motorboating, if the audio thread is blocked by another lower priority thread (typically the user interface). This was the cause of the issue some users ran into when we first released SONAR 8.
In SONAR 8.5 behind the scenes we now have advanced priority inversion detection built in, thanks to some sleuthing work from Keith. In the event that this condition is ever detected, the code will preemptively attempt to recover from this by breaking the inversion scenario automatically behind the scenes. In our internal builds this scenario sets off warning alarms so that the developer can track down the issue. Through our beta cycle we didn’t encounter such problems so the SONAR 8.5 code is pretty robust in this area.
This feature might also be aptly named the motorboat cop. Think of this as the motorboat cop watching your back – he will shut down any illegal traffic in a couple of seconds before it gets too far 🙂
Smooth Looping Optimization
In the audio engine, SONAR has traditionally handled discontinuities at a loop boundary by pumping two partially sized audio buffers one at the end of the loop region and another at the beginning. Over time this was identified as the source of inconsistent behavior and bugs with many plug-ins as well as other features in SONAR such as the EI and plug-in delay compensation code. Although plug-ins are supposed to handle a dynamic change in buffer size, in practice there have been various plug-ins that behave erratically when sent a different sized buffer at a loop discontinuity.
SONAR 8.5 now aggregates partial buffers into a single buffer at a loop boundary. From the outside world this new buffer aggregation makes looping look identical to regular playback from a plug-in streaming perspective (as well as to the rest of the SONAR audio engine). This addresses numerous compatibility issues/bugs where plug-ins could glitch at a loop boundary, cause CPU spikes, lose timing, etc.
Benefits: Looping in SONAR 8.5 should be much smoother and CPU efficient at loop boundaries. UAD plug-ins are one class of plug-ins that benefit but there may be others.
Limitations: Partial buffers are still sent to plug-in’s that reside in clip effects bins at a loop boundary. The reason for this is because the plug-in is tied to the data in the clip. If we were to stream a full buffer to such plug-ins they would be processing data outside the loop region. i.e., in the case of a reverb you would hear a tail for data that isn’t really playing.
VST Optimizations
Minimize VST interleave conversions: Internal to the audio engine in SONAR all audio processing works with interleaved audio buffers. The VST and DX plug-in models have different requirements as far as buffer interleaving goes. DX plug-ins always deal with interleaved audio buffers (typically pairs of L/R channel audio buffers). VST plug-ins on the other hand require mono buffers at process time. To handle this SONAR would de-interleave stereo buffers into dual mono streams before sending them to the VST for processing and it would re-interleave these dual mono buffers back to stereo interleaved format at the output stage. These constant buffer interleave conversions can add to CPU and caching penalties especially at low latencies. In SONAR 8.5 we optimize this by retaining the buffers in dual mono format within effect bins as far as possible to avoid interleave conversion penalties.
Use cases: With projects containing many plug-ins in effects bins the penalty of interleave conversions on buffers can add up. For example in the DawBench project there are many plug-ins in each effects bin. While running such projects at low latency minimizing interleave conversions can be beneficial. For example, this optimization alone buys us about 3-4% in CPU consumption back with an effect laden project like DawBench. To a normal end user this means that more complex projects with lots of VST plug-ins in bins will run more efficiently at low latency.
Detail: The effects processing layer in SONAR now has intelligence about predecessor and successor effects in the bin. It uses this information to determine whether interleave conversions are required or if buffer can be retained in split mono format, thereby avoiding intra chain buffer conversions. If you want to understand this better, read on otherwise skip on to the next section.
Consider the following scenarios in an effects bin, showing how interleaved audio is now managed in SONAR 8.5. In all scenarios below SONAR 8 and earlier would have a DI and MUX step for EACH VST plug-in.
Legend:
====== Split mono data
———- Mono data
<><><> Interleaved audio data
[DI] De-Interleaving process
[MUX] Multiplex (re-Interleaving) process
[BinInput] Effects bin input
[BinOutput] Effects bin output
[SC] Sidechain input
Single VST in effects bin
[BinInput] <><><> [DI] ==== VST1 ==== [MUX] <><><> [BinOutput]
Multiple consecutive VST’s in effects bin
[BinInput] <><><> [DI] ==== VST1 ==== VST2 ==== VST3 ==== [MUX] <><><> [BinOutput]
VST’s in effects bin interspersed with DX plug-ins
[BinInput] <><><> [DI] ==== VST1 ==== VST2 ==== [MUX] <><><> DX1 <><><> DX1 ==== VST3 ==== VST4 ==== [MUX] <><><> [BinOutput]
VST’s with side-chain source
[BinInput] <><><> [DI] ==== VST1 ====\
VST2 ==== [MUX] <><><> [BinOutput]
[SC] <><><> [DI] ====/
Bypassed plug-ins in effects bin
[BinInput] <><><> [DI] ==== VST1 ==== \ (VST2 bypassed)
============== VST3 ==== [MUX] <><><> [BinOutput]
Mono input to effects bin with stereo VSTs
[BinInput] —————- VST1 ==== VST2 ==== [MUX] <><><> [BinOutput]
Limitations: Interspersing DX plug-ins in the bin will force a DI/MUX step since DX plug-ins always use interleaved buffers.
Async Processing for VST Opcodes: In earlier versions of SONAR some VST operations would potentially block the audio processing thread under some scenarios for certain VST opcodes. This could cause audio to stutter while performing expensive operations such as opening plug-in windows. E.g., opening a BFD plug-in window while streaming. This problem could also manifest when the synth rack was open with certain plug-ins loaded such as various Spectrasonic plug-ins. Many of these operations are now asynchronous and do not block the audio thread anymore. As a result performing these operations during playback will not interrupt audio. This additionally also addresses glitches when changing plug-in presets with certain plug-ins.
Additional VST Property – Serialize Host Access: Related to the previous section, there is a new per-plug-in property in the plug-in manager available called Serialize Host Access. If checked, VST dispatcher calls to the plug-in are serialized as far as possible. The default behavior is OFF, which allows asynchronous calls to the plug-in and prevents the audio engine from getting blocked. The only reason to check this flag would be for a plug-in that has thread safety problems leading to crashes. The default behavior is OFF, allowing asynchronous calls to the plug-in. This allows the UI thread to interact independently with the plug-in GUI without impacting the audio engine.
Additional VST Property: Always suspend on Play: The plug-in manager now makes an additional per-plug-in property available called Always suspend on Play. When checked, this will force a plug-in reset when playback starts the next time. This new property is useful when used with “tail generating” effects such as delays and reverbs. As you shuttle around your project stopping and starting from different points you may hear tails which are generated from unrelated material on top of the mix. In some cases you could also have cases where bounces and exports contain residual tails from effects in the project from the last playback. This is especially noticeable when “Play Effect tails after Stop” is un-checked. For VST Effects that generate tails, open the plug-in properties from the Plug-in Manager and check Always Suspend on Play (it is unchecked by default for compatibility reasons).
Notes: for this property to take effect, the plug-in must be re-instantiated.
Windows 7 Ready
Cakewalk was a finalist in Microsoft’s 2009 Partner of the Year Awards and as you would expect from the industry-leading Windows DAW, SONAR 8.5 is ready for Windows 7 right from the get-go. SONAR 8.5 was tested on early Windows 7 betas right through to the final release candidate, and we are pleased to recommended Windows 7 as a great platform for SONAR 8.5.
Additionally, SONAR 8.5 was evaluated at an independent Microsoft application compatibility lab and officially passed Windows 7 compatibility testing. Here is a link to some common questions about Windows 7 and music production apps.
Wider Bridges
With X64 computing finally becoming more mainstream, a goal was improving our 64-32 bit plugin bridging infrastructure in SONAR 8.5, making the 64 bit version of SONAR even more compelling to users of the X64 windows platform. There are several important enhancements to BitBridge and we took it even further by integrating support for the 3’rd party jBridge VST loader, to give our customers the widestrange of compatibility options.
You can watch a great video presentation from Brandon Ryan demonstrating SONAR 8.5’s new BitBridge capabilities here.
BitBridge – Improved compatibility with 32 bit plug-ins: In SONAR 8.5 we invested a lot of resources into identifying and addressing known Bitbridge customer reported compatibility problems. Typical problems were apparent hangs during scanning or patching plug-ins or problems related to copy protection. During the 8.5 cycle we worked with several plugin vendors who contacted us with issues and resolved them. Some examples are Antares, Waves, Spectrasonics and Pace. We are thankful to these companies for jointly working with us proactively to solve compatibility problems.
The following plug-ins are known to be fixed by these changes. There are several others now known to benefit from the same fixes.
• PACE protected plug-ins are now fully supported
• Waves plugins now load under Bitbridge
• CronoX
• Omnisphere
• Sampletank 2.5
• All Antares iLok protected plug-ins
• Camelspace
• Ohmforce plug-ins
BitBridge XR – Extended RAM, multi-server support: In continuation of Cakewalk’s industry leading commitment and support for the X64 platform we improved on the design of BitBridge, adding support for large memory sets even for 32 bit plug-ins. Earlier versions of SONAR X64 could load only a max of 4GB worth of 32 bit plug-ins. The new BitBridge XR now allows for up to 32 independent plug-in servers. Each server can address up to 4GB of RAM, allowing access to a massive 128GB of RAM (the max supported by Vista Ultimate X64 or Windows 7). All this memory is now available to 32 bit plug-ins running under SONAR X64. Server loading is either automatic or customizable allowing the user control over which server to load plug-ins into. This makes SONAR the first native 64 bit DAW that can address all available system RAM even with 32 bit plug-ins.
The BitBridge XR server configuration is managed via the Options | Global | VST Plug-Ins property page. By default SONAR is set up to manage memory automatically. It will allocate and allow access to all available RAM dynamically as plug-in’s are used. It does this by using dynamically created BitBridge servers when necessary. No user intervention is necessary when automatic configuration option is selected. Since SONAR has no knowledge of the memory requirements of a plug-in in advance, it manages memory resources in a round robin fashion across the BitBridge servers.
For ultimate control you can also choose to manage BitBridge servers manually by explicitly selecting the server that you wish plug-in’s to be loaded into. For example this may allow you to more optimally use your memory by packing memory hungry VST’s into their own private Bitbridge server. The actual memory consumed by a server instance is shown in the server list allowing you choose which server you may want to load into.
Notes: Once a specific server is selected, all plug-ins subsequently loaded will be loaded into that specific server, bypassing SONAR’s automatic memory management. This includes projects loaded containing VST plug-ins. At any time you may switch back to automatic memory management by selecting “Automatic”. Any custom server assignments are saved with your project file.
Boundary Conditions: Server management is common across all loaded projects. i.e. if you load a project containing specific plug-in server assignments and then load another document simultaneously. You may overflow the 4GB capacity of a server if the new project references the same server. Under such a condition the plug-in will fail to load. If this occurs close the other project before opening the new one.
BitBridge – MIDI Out VST support: Older versions of BitBridge did not support MIDI generative VST’s. BitBridge XR now supports VST’s that generate MIDI. The following plug-ins are known to be addressed by this update: JamStix
BitBridge – ACT, automation Read/Write, Presets and Solo support: With prior versions it was not possible to ACT enable a plugin or access the automation read/write enable functionality in SONAR, because the plugin window was always hosted within BitBridge. In SONAR 8.5 you can now choose to detach the BitBridge hosted window from SONAR’s effects window. This allows you to gain access to all the SONAR specific plugin toolbar functions such as ACT automation read/write, SONAR presets and the new solo button.
You can gain access to this by holding down the shift key before you double click to open the effects window. This causes SONAR to open both windows the hosted plugin window as well as SONAR’s default plugin view with the toolbar.
BitBridge – Abnormal Termination Watchdog: In earlier versions of BitBridge if a plugin crashed or SONAR terminated abnormally, the BitBridge 32 bit process would be stuck in memory permanenly until you killed it from Task Manager. If this happened while you had a lot of plug-ins loaded in BitBridge, this would block all memory consumed by those plugins, effectively causing a memory leak on the system.
The new version of BitBridge implements a watchdog mechanism. If it ever detects that a BitBridge instance is running without the SONAR host being active, it will auto destruct and force a shut down of the BitBridge server. This self cleans up any zombie BitBridge processes. This is very useful especially when running multiple BitBridge server instances in SONAR 8.5. You can verify this behavior by loading SONAR with multiple plugins under BitBridge and then killing SONAR from task manager. The BitBridge processes will automatically shut down in a few seconds.
VST Compatibility: Open VST Loaders
Cakewalk has always been committed to delivering an open standards environment to our customers to provide them with the best compatibility with 3’rd party plug-ins on both the 32 bit and 64 bit platforms. We are happy to support other vendors who deliver value for the 64 bit platform. SONAR 8 now adds support for the 3’rd party “jBridge” VST bridge. jBridge is an alternate VST loader that hosts VST’s in an external process similar to our built in BitBridge that Cakewalk pioneered in SONAR 5. Like Cakewalk’s native Bitbridge it allows you to run 32 bit plug-ins out of process in a 62 bit environment. An additionally bonus is that jBridge also allows for the following bridging combinations:
• 32 bit plug-ins inside a 32 bit version of SONAR (for “sandboxing” and allowing you to overcome the memory limitations of a single 32bit process)
• 64 bit plug-ins inside a 64 bit version of SONAR (for “sandboxing”)
• 64 bit plug-ins inside a 32 bit version of SONAR (less likely scenario nonetheless).
The symmetric bridging can be useful for “sandboxing” plug-ins that crash frequently. i.e. if a plug-in crashes or corrupts the host memory space in this scenario it will only bring down the bridge not the host application. To enable jBridge, select the “Load using jBridge wrapper” check box in the VST Plug-In Properties dialog from the SONAR Plug-in Manager. When this box is checked SONAR will always use jBridge to load the plug-in instead of our built in loader. Note that you can set this independently for the 32 bit and 64 bit version of SONAR.
Notes:
• This check box is only enabled on systems where jBridge is previously installed.
• jBridge is a 3’rd party tool. Cakewalk does not provide support for jBridge other than the integration described above.
Optimized non linear playback/preview of MIDI/Audio loops and patterns
Prior to SONAR 8.5, non linear streaming of MIDI and audio patterns was used by the Loop Explorer exclusively for preview purposes. In SONAR 8.5, the MIDI and audio preview engine has been redesigned and greatly enhanced to make it robust and suitable for live performance use. This was done in preparation for non linear playback the new Groove Matrix feature.
There is now a new preview manager that handles all clients such as the non linear Groove Matrix, as well as Media Browser and Loop Construction view. Loading and playback of loops and patterns are now available dynamically during playback without interrupting the playback stream. In addition to all the file sources supported in earlier versions of SONAR, the new engine supports native preview of Project 5 pattern (.PTN) files, step sequencer patterns (.SSP) as well as REX loops (.REX).
Additionally, the rendering accuracy for MIDI preview/non linear playback through softsynths has been improved. At higher latencies rendering is much tighter than SONAR 8 due to improvements in time interpolation.
Groove Matrix
What’s the groove matrix? The answer is out there, and it’s looking for you, and it will find you if you want it to. Seriously, this feature is well described elsewhere so I won’t go into too many details here. Integration of the groove matrix into SONAR adds yet another powerful tool to the already well rounded feature set of SONAR. It is now possible do a non linear performance of audio and MIDI content alongside classic linear sequenced material. This can be an invaluable for live performance. (Note: loop based music is not the one application of this powerful tool).
It’s important to know that matrix is not a port of the Project 5 groove matrix – There wasn’t a single line of code that actually came over from the P5 code. It’s a brand new feature that has some similarities with P5 but that’s where the comparison ends.
In a nutshell the matrix is composed of a grid of multiple cells each of which can hold audio or MIDI content. A row can contain MIDI or audio data and can be assigned to either a synth or audio track. Any number of rows in the GM can be assigned to one or more tracks, making output routing of the matrix very flexible. An output from the matrix to a track is internally treated like a send from one bus to another, utilizing SONAR’s universal bussing framework. You can capture the your real-time performance from the output of a matrix row to its destination track at any time, converting it to linear data on the timeline, allowing you to easily switch between a linear and non linear workflow.
Media Browser
Previously called Loop Explorer this view has been enhanced to supports various new media types and integrate with the new Groove Matrix view. It is the primary mechanism to bring in new content into the new Groove Matrix view. It now supports preview of Project 5 pattern (.PTN) files, step sequencer patterns (.SSP) as well as REX loops (.REX). This makes it easy to preview and import these formats into SONAR tracks or the new Groove Matrix.
Previewing multiple files simultaneously: Media Browser now supports simultaneously previewing files of different formats across multiple folders. For example you can now navigate to a folder containing P5 PTN files start up preview of a pattern and then switch to another folder containing step sequencer patterns and start preview of the new pattern without losing the currently previewing P5 pattern (.SSP). This makes it easy to preview how multiple patterns might sound together before choosing to import them. This is done by holding down the CTRL key before selecting a new pattern in a different folder. When an item is selected via CTRL-select, any existing preview items will continue to sound.
Content location presets: Media Browser now supports saving and loading content location presets via a preset picker on the loop explorer toolbar. Content location presets are a new mechanism in SONAR to save the disk locations of frequently used folders. A content location preset saves the path to a folder as a friendly preset name and allows you to quickly navigate to it by loading up that preset. This works like the familiar preset management interfaces used everywhere in SONAR. This is a big time saver to navigate to locations on your disk where you store loops or any other content that you need access to often.
Managing Hardware Changes
SONAR 8.5 has several enhancements to the theme of dynamic configuration changes. When hardware is added or removed, SONAR 8.5 automatically detects this change and picks up the new configuration dynamically. There are several sub features as described below that are related to this theme.
Change I/O devices without restarting SONAR
In SONAR we added support for dynamic audio configuration changes. Following up on this theme, SONAR 8.5 adds support for “hot-plugging” audio and MIDI devices while SONAR is running by detecting and responding to standard Windows device insertion or removal messages. This works with most device drivers that support this protocol. This feature is useful if you want to plug in or remove a USB/Firewire audio or MIDI device while SONAR is running. Another use is to temporarily remove and reinsert a device that requires unplugging to change a parameter like sample rate.
When a device is added or removed, SONAR prompts you to confirm or cancel the change. If you click Yes, playback stops and the audio and MIDI engines reload. If you click cancel, the device change is ignored and your currently loaded device is used. (of course if you removed a device that was in use you shouldn’t choose to cancel)
Notes:
• If playback is underway when the message was displayed clicking ‘Yes’ will stop the transport the engine will reload. After this the new device will be available.
• You should generally stop the audio engine before unplugging any devices that are in use. With some devices this might otherwise result in unpredictable behavior otherwise.
• On removing or inserting a device MIDI and AUDIO port remapping might occur. Please refer to next sections for more details on this.
Preserve selected audio devices on device changes: This addresses the issue of audio port “sliding” whenever new hardware is added or removed from your system. This was caused because earlier versions of SONAR saved the device enable settings in a global pool of inputs and outputs. As of SONAR 8.5, enabled inputs and outputs (as set in Options | Audio | Drivers) are now persisted per device and per driver mode. This prevents audio ports from shifting around and causing unwanted devices to become selected as active audio inputs and outputs. You can add a device back at any time and SONAR will remember the last set of enabled inputs and outputs for that device. You can freely add or remove devices without impacting the current working set of enabled devices. Adding a device back will remember its last selected inputs and outputs. You can also switch driver modes and the existing enabled devices will be remembered for the next time when you switch back to that mode.
Enabled inputs and outputs are now persisted per device and per driver mode in aud.ini. The old [DriverMap] section has now been deprecated and doesn’t apply anymore. A clean aud.ini will not contain this section. . In its place the active inputs are stored under the respective device section under keys named like this:
WASAPI.DriverMap.UseWaveOut1=0
WASAPI.DriverMap.UseWaveIn1=1
WDM.DriverMap.UseWaveOut1=0
WDM.DriverMap.UseWaveIn1=0
Automatic project hardware output remapping
In earlier versions of SONAR, when drivers are removed or inserted, outputs used by a project would either wrap around to available ports, or be assigned to NONE. In SONAR 8.5, as far as possible existing ports are resolved and remapped to the appropriate new destination. Any unresolved ports can be manually reassigned by the user via a new “Missing Audio Outputs” dialog. This is similar to the MIDI port remapping dialog that was first implemented in SONAR 8. This solves problems where outputs would wrap and go to the wrong device when a new device was added or an existing one removed. Also missing devices could cause buses routed to it to be silenced. This feature also allows intelligent remapping of devices across DIFFERENT hardware configurations or driver models, by using the user assigned friendly driver names.
Detail: Project hardware output remapping kicks in whenever the hardware referenced by a project is different from the current hardware configuration. It can occur when you add or remove audio hardware or enable/disable outputs in options | audio | drivers. Remapping happens automatically when possible and when a match is not automatically found the “Missing Audio Outputs” dialog is shown allowing the user to resolve the missing ports. All tracks and buses, sends and outputs that route to the missing destination will be rerouted when this happens. The user is presented with default assignments of the outputs and can click OK to accept these. The default assignment is to assign consecutive available outputs, modulo the number of outputs available, to the missing devices.
If the user clicks Cancel, or picks [Unassigned] from the available devices list, the original missing device assignments are preserved. In this case the output port selection in the application will show the missing device name prefixed by MISSING. What this means is that if you make edits to a project when the original hardware is not present and resave the project file, subsequent loads will RETAIN the original device assignments. This can be very handy when moving projects across multiple computers with different audio hardware.
Remapping using Friendly driver names
There is an additional level of remapping that takes place when “Use friendly names to represent audio drivers” is checked in Options | Audio | Drivers. When this option is enabled, it allows intelligent remapping of devices across different hardware configurations or driver models by using the users assigned friendly driver names even if the hardware names do not match. Consider the following Setup in Options | Audio under WDM/KS and ASIO modes: Notice that the output “Analog 1/2” has been assigned a friendly name of “Speakers” in both WDM and ASIO modes.
If you save a project that uses this output while using WDM mode and then subsequently load up that project while the driver mode is in ASIO mode, SONAR will automatically remap this output to the output named “Speakers” in ASIO mode. This can be very useful if you switch driver modes and load projects you worked on earlier in another driver mode. This feature can also be used to transport projects to a completely different hardware configuration. As long as you set up friendly names that match all outputs will be automatically remapped.
IMPORTANT NOTE: Remapping with friendly names takes precedence over the actual hardware device names. E.g. if you have a friendly name called “Speakers” and you load a project that uses an output referencing this name it will ALWAYS remap that output to the one CURRENTLY named “Speakers”. This will happen even if you subsequently rename another output to be called “speakers”. This is a useful way to redirect the outputs of all projects dynamically at any time without editing them. Note that the “Missing Audio Outputs” dialog is not shown if there is exactly one output available and there is a single “unresolved” missing output. In this case SONAR will resolve this by automatically assign the missing output to the available output since there is no potential choice. This avoids the redundant prompt.
Limitations:
Port remapping does not occur for audio inputs currently.
Friendly name remapping is currently not available for MIDI ports.
Automatic MIDI Port Remapping for Control Surfaces
In earlier versions of SONAR control surface MIDI ports were remapped when the MIDI hardware configuration was changed, but only dynamically while the app was running.
If a different MIDI device was removed while SONAR was not running, on next open the surface MIDI ports for an existing device could get incorrectly assigned leading to loss of communication with the device. We now persist the names of the MIDI in and MIDI out ports assigned to the surfaces in ctrsurface.dat which allows us to do port remapping at app load time on control surfaces.
Limitations:
If the MIDI device IN USE by the surface is removed the corresponding MIDI ports for that surface are set to NONE. On reinserting that device later it will not be automatically remapped to the previous port.
Control Your Panic: The Reset MIDI and Audio button (panic) on the toolbar (User 1) now has an additional mode. If you hold down the CTRL key while pressing the panic button it additionally does a hard reset of the audio and MIDI engine. This forces your audio configuration to be reloaded and also forces the port remapping validation to take place. This can be a handy way to force SONAR to detect a newly added audio device if the device driver does not support device arrival/removal notification properly. It’s also convenient to bring up the missing ports dialog again if you dismissed it without responding when the project file was opened. This was originally added as a debugging aid while implementing the port remapping and device detection features but was left in since it’s useful to force a fresh reload of an ASIO device that has stopped working as one example.
Miscellaneous
Help is on hand:
Clicking Help | Cakewalk Problem Reporter now takes you to our web portal to report a problem directly to us, if you encounter a problem while using SONAR.
Quick Open Minidumps folder:
While submitting problem reports there is a handy way to open the minidump folder where all Cakewalk crash logs are stored: Click Help | About SONAR, while holding down the ALT key, click the trademarks button. This will open the folder where all crash dumps are stored. Crashes from plug-ins are stored in a separate folder to allow finding them easily.