The SONAR 8.3 Log
We're happy to see so many of you enjoying SONAR 8.3. I know some of you enjoy the trivia that goes into a release so here is the unabridged version of what went into SONAR 8.3 aka the making of SONAR 8.3 aka the 8.3 fine print. If details aren't what you like wading through, just go ahead and enjoy using the product and skip this, what you don't know wont hurt you :-)
Disclaimer: This text is not an official Cakewalk endorsement of any features in 8.3 and has not been officially proof checked for accuracy, so I reserve the right to edit the content at will. The sole purpose is to provide more detail on the depth of some of the features in 8.3 that some of you have requested and to hopefully answer some common questions.
8.3 was a particularly intense point release for us and everyone involved spent a lot of long hours and effort to make this happen. Special thanks go out to our beta testers on this who spent long hours trying out all the new risky stuff. Posts from beta testers and Cakewalk engineers going into the wee hours of the morning attest to some of the dedication in this cycle.
As most who have been our customers awhile may know, the typical Cakewalk product lifecycle goes somewhat like this:
- We work on a major release
- Post release we typically do a quick minor point release to address any immediate or urgent issues that might arise
- We then hibernate a bit and do a major point release that makes some feature improvements and addresses any old or new issues that are common customer complaints.
- The cycle repeats
This time around when it was time to do our point release we wanted to continue working on the optimization theme we started in S8, but also revisit some common complaints and workflow issues with some of our existing features that needed some TLC. So we identified the following broad areas that we needed to work on in 8.3:
1. External Insert Improvements
2. Optimization and multi-core enhancements
3. VS-700 updates
4. New/Enhanced Features
5. Bug fixes
6. New content
External Insert Improvements SONAR 8.3 includes a completely reworked and redesigned external insert. We added support for External Inserts back in SONAR 7. Inserts can be a surprisingly complex feature to implement in a DAW, especially with all the variables involved with delay compensation and bussing, etc. We did a lot of work to implement this in SONAR 7; alongside implementing side-chaining (has a few areas of overlap with external inserts in our engine). Though our first cut of external inserts from S7 worked in simple configurations, it was a bit quirky to set up, system dependent and didn't quite work well in more complex configurations where you needed multiple inserts, or used delay compensated plug-ins. Some symptoms included pings not returning consistent results, phasing issues and problems with delay compensated plug-ins and multiprocessing. So we really wanted to try and address all those issues.
Once we were finished with S8, the first step was to identify all known problems with inserts. We went through our bug tracking database and also some test scenarios to collect this. Next, Bob and I took a step back and spent a few days analyzing the existing design on a whiteboard and trying to poke holes in it. Not surprisingly we found quite a few.:-)
After various unsuccessful experiments to build on the existing framework we had in place to process inserts, it became evident that we needed to make some fundamental changes in the loopback logic we had to properly support delay compensation. It turned out to be a daunting task way beyond bug fixing that took over a month to get right, and required some fairly fundamental changes to our rendering logic to pull this off. We had more than a few dark days where nothing we did seemed to work just right or it would get a little better but then something else would break etc.
We love challenges however, and by early January after a couple of breakthroughs and some out of the box thinking, we were psyched to see that we could get reliable pinging and consistently sample accurate playback across a variety of systems. On most interfaces, if the gain stages are set up right you can now get results that are sample accurate, without any tweaking whatsoever - amazing! Even better unlike S7 the new logic worked in WDM mode, without any tweaking.
Another area that that took some special work was to handle the presence of other PDC plug-in's before or after the EI in an effects bin. This was tested by adding one or many plug-ins with huge PDC before and after the EI and testing for phase cancellation.
When we finally went to beta with this we had beta testers running many EI's simultaneously in PDC laden projects with no problems, something that was impossible before. A nice thing about using EI's is that they consume minimal CPU since there is no host based DSP load - all the host is doing is the mixing and routing of the loopback circuits.
Setting up external hardware loopback to be perfectly sample accurate is not always a requirement, but it can be depending on your use scenario. For example, if you are recording multitrack drums and have bleed on the inputs being processed through an EI, you want the loopback to be as phase accurate as possible to avoid weird phase cancellation or other artifacts. At my request Bob Damiano (our director of engineering and a professional audio engineer in a previous life) wrote an excellent EI setup guide that is now in the help. I highly recommend checking that out since there are some great tips in there for setting up an EI. You can read it
online here. The EI qualifies as one of the most challenging projects I've worked on at Cakewalk, but I'm glad to get this one behind us. :-)
Aim Assist - Select Tool When the left mouse button is clicked and held to drag the front of a Clip (the front half), the Aim Assist line snaps to the front of the Clip and travels with the clip as it is dragged.
If the mouse is over the rear of a Clip (the rear half), the Aim Assist line snaps to the end of the Clip, and any snap operates on the clip ends (versus the front). The line again travels with the end of the clip as it is dragged. In other words, the end of the clip is snapped to the current snap settings and landmarks.
Aim Assist - Scissors Tool The Aim Assist line operates normally, but obeys snap, so you can see where a cut will be made.
Aim Assist - Ruler When dragging in the ruler, the former select by time has been restored
Aim Assist enhancements: follow snap settings, clip start
Snap Enhancements - Presets Presets have been added for the Clip property page (only) in the Track View.
Snap Enhancements - Multitrack Landmarks When selected, landmarks from all visible tracks populate the landmark database.
When not selected, the Landmark database consists of the Track the mouse is over (as before).
Clip Groups Enhancements Copying grouped clips now optionally do not include the copied clips in a group
CreateNewGroupsOnPaste=<0 or 1>
Type Boolean
Default 1
When you copy and paste clips that belong to a clip group, this variable specifies if the pasted clips should be placed in a new clip group or continue to be grouped with the original clip group. By default, a new clip group is created.
The values are as follows:
0 = The pasted clips will belong to the same clip group as the clips that were copied.
1 = A new clip group is created for the pasted clips. This is the default behavior.
New split options for clips Split Selection is now an option (see Options | Global | Editing.
Selection after single split -- This list lets you specify what is selected after a clip is split into two parts:
Left portion (default). Only the left portion is selected.
Right portion. Only the right portion is selected.
Both portions. Both the left and right portions are selected.
None. Neither portion is selected.
New checkbox for splitting clip groups:
When splitting clips in groups, create new groups--Choosing this option tells SONAR to create a new clip group when splitting clips in an existing clip group.
Dynamic arm improvements Under Transport | Record Options | Allow arm changes during playback/record there is an additional option for 'Only Inputs In Project'.
The new Only For Inputs In Project option instructs SONAR to only open hardware input ports that are currently active in the project (i.e. assigned to a track).
To only open active hardware input ports
On the Transport menu, click Record Options to open the Record Options dialog.
Select the Only For Inputs In Project check box.
Note: If this option is enabled, you will not be able to change inputs while recording.
Global Effects bypass SONAR has had the ability to bypass effects at a per-effect level (effects bypass) as well as at an effects bin level (bin bypass) or for a selection of tracks.
SONAR 8.3 additionally adds the ability to temporary globally bypass all effects in a project either for all effects bins or by category (tracks/buses/clips).
There is a new toggle in the Process menu globally bypass effects bins. By default global bypass is OFF, which means that all effects bins follow their bypass state as stored in the project.
The “Global Bypass Effects Bins†option temporarily overrides all the effects bin bypass states and forces all track, bus and clip effects bins to be bypassed. The default keyboard accelerator for this is Ctrl-Shift-Y. To restore the bins to their original state, simply toggle the state of the global bypass.
Note that the individual effects bins bypass states are retained during a global bypass operation. While in a global bypass state you may choose to enable any individual effects bins. This provides for an easy way to quickly audition a single effect within a mix.
The use cases where this is handy are:
- To quickly A/B a dry vs. a wet mix
- To temporarily bypass all inline plug-in delay compensation (PDC) effects in order to avoid delay compensation induced latency while tracking virtual instruments or input monitored tracks.
- To temporarily reduce CPU consumption
New Track/Bus/Clip effects Menu toggle - Bypass Bins of This Type This is a new popup menu item on tracks, buses and clip effects bins.
By default Bypass Bins of This Type' is OFF, which means that all track, bus, or clip effects bin's follow their bypass state as stored in the project. When 'Bypass Bins of This Type' is enabled, all effects bins which match the data type of the source effect bin are bypassed. E.g. If you pick this operation from a track effects bin, ALL track effects bins will be bypassed. If you pick this operation from a bus effects bin, all ALL bus effects bins will be bypassed.
The “Bypass Bins of This Type†option works similarly to the global bypass bins operation except that it operates on a more limited set of data as specified by the source bin from which the operation is performed.
Note that the individual effects bins bypass states are retained during this bypass operation. You can freely mix and match using 'Bypass Bins of This Type' with other bin bypass operations. Not that the global 'Global Bypass Effects Bins' option if toggled will override any individual 'Bypass Bins Of This Type' operations since it operates on a wider scope.
PDC Override For Live Tracks We had a common feature request to allow for low latency playback even in projects with PDC plug-ins. While working on all the delay compensation stuff in the EI, I had an “aha†moment. The work with the EI revealed that there was a more straightforward way to make this happen. It took just a few hours to implement this useful feature with the new approach. I love it when another feature enables a seemingly unrelated sub-feature!
While working with virtual instruments and live input monitored tracks one of the primary requirements is for audio to be streamed at low latency to minimize delay. Although SONAR itself supports streaming audio at very low latency (subject to any hardware restrictions) there are cases where internal buffering can cause additional latency. There are several scenarios where this can occur, the most common being when you have plug-in’s that require automatic plug-in delay compensation (PDC).
For example, a track may have a plug-in such as PerfectSpace or TransientShaper, which needs more than one buffer of audio before it can produce output. Depending on the signal flow in the project, the presence of such plug-ins can cause other normal tracks to be Delay Compensated in order to synchronize them with the delayed audio. The process of synchronizing tracks with one another in this way is referred to as Automatic Plug-in Delay Compensation (PDC).
In SONAR whenever delay compensation takes place on a track that has a live input (such as an input monitored track or a synth track), it is delayed by the required amount to synchronize it. In some cases the delay can be so large that it makes live tracking unusable. Additionally, it can also be difficult for an end user to determine exactly what in the project is causing the track to be delayed since there is no feedback as to which plug-ins are producing the delay. It is very common to hear end users ask why their synth’s have high latency even though their audio buffer settings are small.
The
PDC Override for Live Tracks feature allows the end user to disable SONAR’s delay compensation mechanism on all live input circuits in the project, thereby removing the latency on playback and recording of such inputs. This restores the latency to that of the selected audio buffer size (plus any delay incurred by inline plug-ins in the circuit, if any).
There is a new toggle in the Transport menu to enable or disable PDC override on live input tracks. By default PDC override is OFF, which means that all tracks are automatically delay compensated when plug-in’s requiring delay compensation are present. The default keyboard accelerator for this is Ctrl-D.
Note:
- You can control which tracks are delay overridden by enabling input echo only for those tracks. Only input echo enabled tracks are delay overridden – all other tracks have normal delay compensation applied.
- The PDC override feature is automatically turned off during a bounce or export, so it's unnecessary to remember to turn it off manually. i.e it will not affect any rendered output either when using fast bounce or realtime bounce.
Some PDC Override use cases This is primarily useful in cases where you have delay compensated plug-ins in a project, causing other live synth or input monitored tracks to be delayed. Turning on PDC Override in this scenario overrides SONAR's automatic delay compensation only for these tracks thereby allowing them to be rendered with no delay. Since it's a toggle, you can quickly turn it on complete your tracking at low latency, and turn it off when finished to hear the track compensated as normal.
Below are a few common scenarios under which you will hear PDC induced delay on a track. The track which experiences the compensatory delay is shown in red below. Note in all cases Track B is either an input monitored audio track or a Synth track with input echo on. In all the cases shown below, toggling the Live Input PDC Override setting will eliminate the delay on the indicated track.
Cases with PDC plugin in track effects bin:
Track A -------------> PDC trk plug-in -------------\
                                                                       BUS
Track B -------------------------------------------/ Track A -------------> PDC trk plug-in ----------> Hardware Main
Track B ----------------------------------------> Hardware Main Case with PDC plugin in bus effects bin (Trk A routes to bus):
Track A -------------> PDC Bus plug-in -------------\
                                                                         Master BUS
Track B --------------------------------------------/ Boundaries and Exception Handling 1. PDC override is ignored during a bounce/export or freeze operation.
2. If the live track being monitored also contains track data (or MIDI data in the case of a synth track) the streamed track data will not be delay compensated with other tracks. i.e:. it will sound out of time. This is by design. You should either clip mute this data, work with an empty region of the track, or use an entirely new track while recording to avoid confusion.
3. Additionally, routing such as the one illustrated below will cause sync problems when overridden. Track A and B are normal audio tracks and Track B is a synth track with input echo on.
Track A and Track C below will sound out of sync when PDC override is engaged.
This is because synth Track B causes the ENTIRE Bus A circuit to be PDC overridden, leading to delay compensation being bypassed for Bus B.
As a result of this track A and C will be out of sync with each other.
Track A -------------------------------------------\
                                                                       BUS A --------> BUS B
Track B -------------------------------------------/ Track C -------------> PDC trk plug-in -----------------------------/ (to Bus B)
The examples above illustrate the complexities with PDC and why having automatic delay compensation on is a good thing to have on by default :-)
In general to effectively use PDC override without affecting other tracks, the following options are suggested, to avoid dependencies like shown above:
- Output the IM tracks directly to the FINAL bus in the signal flow.
- Send IM tracks directly to a hardware main.
Limitations - The Live Input PDC Override option will not help reduce latency caused by inline plug-ins that have internal delay. ie plug-ins like Perfect Space or TS64 when present in the signal path of an input monitored track will always delay the track irrespective of the state of the Live Input PDC Override option. This is expected since the delay is caused by the plug-in itself and not SONAR's PDC mechanism.
- This feature primarily is of use for live input monitoring and synth tracks. Monitoring though tracks that already contain recorded data will result timing in out of sync playback of the existing data.
- The Live Input PDC Override option can be toggled dynamically during playback. It will cause a momentary “gap†in playback while it resynchronizes.
- The Live Input PDC Override option cannot be toggled dynamically during recording. This is by design.
Optimizations Take 2 More of the same class of improvements that we did in SONAR 8.0, but better!
1. Greatly reduced system calls overhead during realtime audio streaming. Our system calls/sec is around half of what is consumed by 8.0.2 at the same latency!
2. By careful profiling we were able to improve the performance of SONAR's task scheduler by making various optimizations. The scheduler itself now consumes fewer resources and is more efficient at task dispatching.
3. Further reductions on kernel mode transitions
All the above translate into less CPU use at lower latency, allowing you to work at lower latencies than ever before with no glitching.
We will be publishing our internal benchmark results soon but several internal and beta tester reports show average gains of 10-15% on heavily laden projects when comparing performance of SONAR 8.0.2 to SONAR 8.3. We are interested in your observations as well so please post your results.
Improved/more accurate CPU Metering With all the optimization work done so far, it was appropriate to turn our attention to the actual measurement of CPU load. Keith Albright spent a lot of time tweaking and improving the actual measurement of CPU resources in SONAR. You will find that CPU measurement is now more responsive and accurate than before. Also the measurement of CPU load itself is also more efficient (what a concept - the observer effect causing load!)
It's important to understand what SONAR's, CPU meter actually measures compared to what Windows measures in task manager and other tools. From the point of view of a DAW, we are typically interested in measuring how much CPU bandwidth is available before audio drops out or glitches. This is however a simplistic estimate, since on a modern multi-processing OS like Windows there are so many background factors at play (drivers, OS, other background applications or services) that there is no guarantee that there will not be a glitch caused by some external interruption. Despite this the CPU meter still serves a very useful purpose and is a good measure of system stability and performance - especially on a well optimized system. SONAR's CPU measurement can be expressed by the following formula:
CPU% = (BufTimeMs / BufDurationMs) * 100.
BufTimeMs = Time taken to process a single buffer of audio in milliseconds
BufDurationMs = Duration of a single buffer of audio in milliseconds
i.e. a CPU % of 100 means that your computer is taking as much time to process a buffer of audio as the duration of that buffer itself. In other words this is a dropout condition.
By default, SONAR doesn't dropout if it encounters a single buffer of audio that takes longer to process than the buffer duration. We do this so that the application is not overly paranoid and dropout prone while doing edits. Instead we wait for a threshold time of CPU over's before we force a dropout. This threshold is user configurable via aud.ini as documented in the help file.
DropoutMsec=<num>
Type: Integer
Default: 250
Under high system load conditions, the SONAR audio pump mechanism may become starved. When this condition is detected, SONAR drops out. The DropoutMsec variable allows you to configure the tolerance time in milliseconds. This variable applies to all driver modes.
Setting DropoutMsec to a positive value > 0 specifies the actual time in milliseconds to tolerate before dropping out due to starvation.
Setting DropoutMsec to a negative value < 0 means we use a multiple of the audio buffer size as the tolerance. i.e. -2 means we use twice the audio buffer size.
Note that setting this value too low (e.g. 0) can result in more frequent dropouts in the program. If you notice too many dropouts, try raising it in buffer multiples or by explicitly specifying a millisecond value.
CPUMeterMode With the proliferation of multi-core systems available today the old way of displaying CPU load on the taskbar needed an overhaul. Instead of toggling the display between the available CPU's (try watching that on an 8 core machine <g>) by default on the taskbar we now display a peak and an average value, similar to what our audio meters display. This is much more useful than the prior approach. Of course you can always see all the individual meters on the large transport.
We even went a step further and made this customizable. You can switch the taskbar CPU readout to one of 3 modes:
CPUMeterMode This variable specifies how the CPU meter appears in the status bar on multiprocessor systems. The values are as follows:
0 = The peak thread load is displayed as the bar and a yellow indicator shows the average of all audio threads. This is the default mode.
1 = The average audio thread load is displayed as the bar and a yellow indicator shows the peak thread.
2 = A bar is shown for each audio thread. This is the same display as previous versions of SONAR.
Improved Multi-Core load balancing SONAR has supported scalable load balancing for multi-core computers since SONAR 3. In 8.3 we spent some time researching different techniques to improve our task scheduler (the internal component that distributes the project workload across multiple threads). The new scheduler mechanism allows for a more even load across all cores on a multi-core system. Not only that but the new mechanism consumes less CPU and is more power efficient. We haven't measured this yet but it should actually consume less battery resources on a notebook than SONAR 8.0.2! SONAR goes environment friendly :-)
Since all systems are not made equal we decided to make this new scheduling mode configurable ïŠ
From the help file, the new aud.ini option to control this is:
ThreadSchedulingModel=<0 - 2>
Type Integer
Default 1
This variable goes in the [Wave] section and controls the interaction of the main audio thread and worker threads on multiprocessor systems when the Use Multiprocessing Engine option is enabled. Depending on the system, a particular model may result in less glitching and better overall performance. The values are as follows:
0 = Same as previous versions of SONAR.
1 = (default) Better thread balance. Model is more efficient and can provide cycles for other tasks.
2 = Additional worker thread is created. This may result in improvement with Quad processor systems or higher. Not recommended for Dual processor systems.
New 64 bit plug-ins There are 2 new 64 bit plug-ins included with SONAR 8.3. These plug-ins will load natively in SONAR X64 without using BitBridge
Guitar Rig 3.2.2 LE
TruePianos x64
Improved native plug-in selection in Vista X64 SONAR X64 will now preferentially pick the X64 version of a plug-in when both X64 and X86 flavors are available in the plug-in inventory. When running 32 bit SONAR in Vista X64 it will pick the X86 (32 bit) version of the plug-in.
New application error notifications Too many plug-ins notification SONAR has limits to the number of plugin's that can fit in menus. When the number of plugin's exceeds the limit we now display an error message:
"More plug-in's are available on your system than can fit on this menu. The extra plug-ins will not be listed until this is resolved. Please use the Plug-in Manager to create custom menu layouts in order to categorize and store smaller sets of these plug-ins. Alternatively you can reduce the number of plug-in's installed on your system."
This normally happens when you have too many plugins installed on your system than can fit the menu. You need to move some plugins out of your default VST folder or alternatively use plugin layouts. Layouts were designed to overcome this problem.
The current limits for how many plug-ins can fit in the menu are:
735 audio plug-ins
255 synths
31 rewire devices
Though these numbers might look arbitrary, they are the ranges assigned to menu identifiers.
Notification when track/bus outputs are assigned to silent output A new Silent Busses Detected dialog warns the user when a project contains buses or tracks that are assigned to the silent "NONE" output destination. The dialog lists all tracks and buses that have outputs or sends that are assigned to "NONE"
Typically if there is a discrepancy detected between the port assignments that were saved and the ports that are used in the current configuration, the ports are set to "None" and the Silent Busses Detected dialog warns the user.
This can also happen if you change your driver mode and fewer output devices are available in the new mode.
The message is primarily intended to be a warning to alert the user that a bus might be silent since it might be unexpected. No action is required if the user intentionally assigned the bus or track to NONE.
If you never wish to receive this warning message there is a cakewalk.ini option to silence it.
In Options | Initialization file add a new variable named WarnSilentBuses and set it to 0.
Issues addressed In all our point releases we address a large number of user reported problems as well as issues internally identified in order to improve stability of our application. Below is a sampling of some of the issues that were addressed in SONAR 8.3 from our internal database.
Synth rack view doesn't redraw when creating track folders
Abbey Road Brilliance Pack causes memory leak in 8.0.1
LP64 EQ could cause crash when in master bus
Slow Saving with East/West plug-in
Fix for certain project files that could crash on load
Crash while enabling built-in EQ during playback in x64
Huge GDI jump when adding an envelope to some projects
Crash while idling after loading a project
Plug-in Manager Crashes when exporting ACT or surface presets
Assert and hang patching External Insert under x64
Automation does not work before looped region in a project
Cannot reorder MIDI outputs with VS-700
Disk meter updates infrequently at low latencies
Incorrect processing of WM_APPCOMMAND message
Instrument track disappears when you freeze it after choosing to hide MIDI tracks
Copy / paste from Clip Selection group should create new group
Recording two tracks with same input not working in dynamic arm mode
Fixed out of order takes on loop recording
Audio is significantly out of sync with two External Effects on a track
External Effects latency test grows by 3ms each time the ping test is run
External Insert offset changes between passes and sometimes during playback
External Insert ping could appear to hang when the containing bin was bypassed
Wave Profiler allows you to minimize and run SONAR with it in background
Can't audio scrub with EI in project
Unfreeze audio with External Effects Insert causes TTS-1 to break up
Project with multiple External Inserts causes "buzz" when playback is stopped
Deleting EI plug-in causes Sonar crash 2
External Insert sample offset does not behave predictably
Loop Explorer view does not respond to Next button on CS (or CTRL + F6 Tab)
User submitted project fails to load
Automating parameters on External Insert causes crash
Record meter scale doesn't persist
Disappearing Audio w/Drag & Drop
V-Vocal: Mute/Solo affects wrong track if project has instrument tracks
Send Assistant: Can't create pre-fader sends with no effect
Using external insert on track with groove clips causes SONAR to crash
Crash opening MIDI type 1 file in SONAR 8 (x64)
Audio Options Dialog needs Hour Glass when updating
Problems Deleting and Undoing External Insert
Cloning a track containing an EI or drag copying it breaks the source EI
SONAR crashing when archiving tracks with two instances of BFD2 in project
Free Edit tool does not have a way to Split at selection.
Grouped clips in layers select unpredictably when using alt-click-drag
Split Clips at AudioSnap Pool is an available option with no clips selected
Can't Jog by one frame in VS700
Cannot open certain .wrk files in SONAR 8 x64
Clip Groups disengage and cause problems with dragging to the left.
Dropouts with dynamic arm
Using UAD RE-201 + SPL TD together causes motorboating
SONAR and UAD Precision Multiband causes high latency while input monitoring
Metronome toolbar buttons behave inconsistently
Instrument Track MIDI channel jumps to 3
Consistent crash trying to unfreeze a frozen synth
Buss preview waveform loses sync with playback
More than one EI in the same signal path not calculating delay time properly
Preset dropdown in External Insert does not work as expected
Crossfades not working properly
Loop Explorer can not do Key Bind
SONAR crashed when use Input Quantize
Snap to markers doesn’t work sometimes
Scrub Tool doesn't operate on Frozen Simple Instrument Track
Sonar changes output device without warning
Cannot use time/pitch stretch in x64
Error when inserting Pristine Space
MPEX not disabled in x64
Inconsistent PDC behavior
MIDI Clip Length erroneously increases
Deleting EI during play back caused Sonar to crash
Using more than one instance of EI causes failure of the EI return signal
Opening Loop explorer breaks EI on a buss
Fade on stop would not always render for the specified fade time.
post edited by Willy Jones [Cakewalk] - 2009/12/14 09:25:31