Could you add a "link" sliders button to the Concrete Limiter, rather like waves L1,L2.
 

Great to see Cakewalk is really back!
 
1. Lots of sampling rate incompatibility
Check my post.
http://forum.cakewalk.com/Bundled-Plugin-Compatibility-List-Sampling-Rate-m3496351.aspx
 
2. VC Runtime
a)
If you include vcredist 2017, 2015 is not required and should be avoided.
2017 is made as updated version of 2015, unlike other versions.
You can remove vcredist2015_x64.exe and vcredist2015_x86.exe from the installer.
 
b)
These files are not referred from any exe and dll.
I think these are from early version of SONAR.
mfc42u.dll, mfc71.dll, mfc71u.dll, msvcp60.dll,
msvcp70.dll, msvcp71.dll, msvcr71.dll
 
c)
VC 2005 Runtime is referred from some exe but vcredist2005 is not included in the installer.
LoadReg64.exe, CakewalkPublisher.exe
Ignore this info if you exclude 2005 runtime in purpose.
 
3. 2 Boost11 is included.
One looks to be old.
Cakewalk\Shared Utilities\StBoost64.dll : v17.0.3.33
%VSTPLUGINS%\Boost11\Boost11_64.dll : v17.13.3.32
 
<ad>Contact me if you need those QA/QC with coding experience</ad>

Re notation - maybe they can reheat the potential incorporation of Overture??
 
http://forum.cakewalk.com/Message-from-Don-Williams-Overture-5-Updated-m3699129-p3.aspx
 

Last spring two of us flew to Boston to meet with Cakewalk to worked out a deal to put very, very, good notation is Sonar and add some of my upcoming products in the Cakewalk store. The notation would contain 80% of what Overture can do and was to have full integration with Sonar. We agreed to terms, everybody walked away happy, and Cakewalk presented the deal to Gibson. After a month or so, Gibson turned it down, claiming they would have too much financial liability. After the disappointment, I met with a Cakewalk person at Summer NAMM and I agreed to worked out a new deal limiting Gibson's liability. Cakewalk liked the new deal and all of us were very excited, thinking Gibson will not turn down the new terms. To our shock Gibson said no. Cakewalk knew the importance of the deal to Sonar and was left feeling helpless. I felt bad for the guys at Cakewalk and on my own decided to help Cakewalk by offering to put a free light version in Sonar at no cost to Cakewalk or Gibson and we would sell an upgrade that provided full notation for a very small price. This was a no brainer, right. Guess what! Nothing ever happened, and I even have an alpha version working

.

Thanks Meng!!
1) Feature - A revamp for TTS-1, it looks like a Windows 98 plugin.
2) Feature - Updates for Sonitus plugins, they are abandoned. 
3) Feature - I miss and acoustic piano in the Studio Instruments Suite.
4) Feature - A midi Drum Editor. 
5) Workflow - Making custom drum maps is a pain. I would appreciate the possibility of writing the custom names directly on the  virtual keyboard as in Studio One, Cubase and REAPER.
Greetings from Spain and congratulations for the hard work!
P.D.: And sorry for my poor English 
 

I would like to see an "archive" button much like mute, but this function would disable the whole track within the project. Often I have tracks that are unused on the mix that I don't want to delete. So the archive function would not only mute, but disengage the track from memory and any other processing. The only thing you should be able to do while it is archived is to unarchive or delete the track.

14 yrs ago...! I vaguely remember that P5... Wow. Gr8 ideas abound. Stability 1st, NOTATION, drum map via reaper. Score view.

robbie111222
1. I use a lot of exported midi drums from guitar pro 5 and it takes tonnes of time manually editing the cymbals for velocity and snare and kick to sound more natural.  I would love to have a feature in CAKEWALK that made this simpler or automatic- for instance having a drum editor that automatically takes hi hats and intelligently randomizes velocities with harder hits on beat 1 and 3 or having lots of options like adding a ghost note before or after a snare hit.  Perhaps a feature that moved snare hits slightly forward or behind the beat to add a groove.

I believe you can do it using Groove Quantize, or even by CAL. Both have been Cakewalk features since earlier '90 Cakewalk. Most people just don't use it because they never learn how to utilize these features, let alone to master it. Please take some time to learn to use them. Hope it helps.

Fishmed
I would like to see an "archive" button much like mute, but this function would disable the whole track within the project. Often I have tracks that are unused on the mix that I don't want to delete. So the archive function would not only mute, but disengage the track from memory and any other processing. The only thing you should be able to do while it is archived is to unarchive or delete the track.

It already exists and is called...the Archive Button (a big A button per track).  It may be hidden in the default widget view, but it can be added by checking Track State in the widget manager.

KPerry

Fishmed
I would like to see an "archive" button much like mute, but this function would disable the whole track within the project. Often I have tracks that are unused on the mix that I don't want to delete. So the archive function would not only mute, but disengage the track from memory and any other processing. The only thing you should be able to do while it is archived is to unarchive or delete the track.

It already exists and is called...the Archive Button (a big A button per track).  It may be hidden in the default widget view, but it can be added by checking Track State in the widget manager.

Awesome, thanks for the info. I did not know it already existed.

Hardware I/O Aliasing and Routing (Improved Friendly Naming)
 
Currently in SPLAT, here’s what it looks like whenever I want to select a bus output or a send output:
 

 
A similar menu is shown for inputs.  I have more than 2 dozen each of inputs and outputs:  which means I have a LOT of scrolling to do whenever I want to route something.  I will most often want to route something to a Bus, all of which are mapped BELOW the hardware outputs in this menu.
 
This has been the case since at LEAST Sonar 7, and it was a “worst in class” implementation THEN.  So far as I know, it has not been touched since the introduction of Friendly Names. There are a LOT of problems with this implementation.  To be blunt, I have been baffled for more than 10 years why these fundamental features weren’t addressed to be more user-friendly interface.  The users on the forums have complained and requested improvements for literally every version of Sonar that I have used, so far as I can tell.
 
Basically, the way I/O menus are set up, anything more than a few channels in the Driver gets unwieldly to navigate.  The menu always lists all I/O in sets of 3 as “Left, Right, Stereo.” There is no compelling reason to do this (other than ease of programming with respect to how the operating system manages drivers), and there is no way to modify this arrangement, even using Friendly Names.
 
Secondly, the menu ALWAYS has hardware I/O at the top, followed by Aux Bus Channels in the Session, followed by Plugin Side-chains, followed by Functional Options like “New Stereo Bus.”  
 
Here’s a screenshot when adding a send in the Console View:

Why not make each of these a separate sub-menu, along with mono hardware, stereo hardware, and surround hardware groups each in their own sub-menus?
 
In contrast, compare this to how the equivalent dialog looks in Pro Tools 9:
 

It’s still got the Stereo/Mono listing, but it (a) splits up different output types (hardware/bus) into different sub-menus, and (b) formats the list so it’s MUCH easier to navigate.
 
Here’s the input menu in Reaper 5, which is slightly better still because is separates mono and stereo inputs into their own sub-menus.:

 
In reality, I’d like to see something even more structured than this, with commands in the top menu, and mono/stereo/surround/custom inputs and outputs each provided in their own sub-menus for hardware, and again for any existing busses.  Side-chain I/O would go in its own sub-menu as well. I vaguely recall a forum member making a mockup of a better I/O menu based upon their experiences in Studio One, but I couldn’t find the image in the forums again (this would have been years ago at this point).
 
Ideally, Users would be able to create their own custom I/O menus using custom aliases, similar to how they can make their own plugin layouts.



Relatedly, setting up the Driver Aliases is also bare-bones basic in SPLAT right now.  There’s a one-to-one correlation between a stereo pair of drivers and a stereo pair of aliased Friendly names.  
 
Compare that to how I/O is set up in Pro Tools 9:
 

 
This is a lot more powerful.  For one, you can map any mono driver to any Mono Hardware Alias, and it’s very easy to set up stereo pairs.  For some I/O, you don’t even have to match individual channels to their respective stereo pairs (another DAW that does this is Ardour, which has basically no rules whatsoever for routing, though the Pro Tools dialog is MUCH easier to understand).
 
Additionally, it’s organized in a very easy-to-read setup, with separate tabs for inputs/outputs and busses (and other I/O elements within Pro Tools).
 
One other HUGE advantage in Pro Tools is the ability to Import and Export I/O settings, so users can make templates based on project needs, hardware changes, or as a safety setting in case of failed experiments with I/O options.  Importing and Exporting I/O mappings would be a HUGE improvement.




Mix/Edit Grouping Options
 
Currently in SPLAT, you have the options to put individual audio clips into an edit group and individual mixer controls into groups.  This is a GREAT feature, but it would be nice to be able to put clips into multiple groups that have a hierarchy and individual groups can be enabled/disabled through a dialog.  Pro Tools has this sort feature and it’s often very handy.
 
I think we should keep the granularity as is (individual clips and mixer controls, rather than entire channels as in Pro Tools), but otherwise like the idea of stackable groups that can be activated or de-activated as necessary.





Narrow Strip Controls
 
In the current Console View, here’s a Wide and Narrow Strip side-by-side:

 
The wide strip provides 2x the number of buttons in the MSR section, and sometimes those missing buttons are very handy (especially automation modes).  A narrow strip that includes the entirety of those buttons from the wide strip would be very handy. Also, the Pan and Input Gain (not shown) knobs are quite big and take up a lot of screen space (but also leave a lot of dead space around them).  
 
Compare these to, for example, Sonar Producer 8.5:
 

The pan and input trim controls in the mixer are much more compact, which is handy for a narrow strip mode.  Note also that Sonar Producer 8.5 provided equivalent buttons in the MSR section, too. I miss this since Skylight was implemented.
 
Plugin Encapuslation
A feature I’ve heard about in Bitwig, but never experienced firsthand is what they call their “Sandboxed” Plugins.  Basically, each plugin in each channel is instantiated independently of other plugins in the channel, and independently of the DAW at large.  This means if a plugin crashes or throws a bad output, the DAW will recognize the fail condition and safely shut-down that plugin without crashing the entire DAW.  The plugin is effectively bypassed until the user restarts the plugin or removes it from the signal chain.
Having these encapsulated implementations for plugins (and Pro Channel modules, which are basically proprietary plugins) could potentially lead to a much more stable environment, especially for users relying heavily on third-party plugins that may not have been tested using Cakewalk.



Timeline Options
One feature that would be nice is the option to include a “Red Book” timeline, which is counted in HH:MM:SS:FF (hours, minutes, second, frames).  Except in this format, there are 75 frames per second, like when you burn an audio CD. This feature would be especially handy when generating cue sheets (which I still do a LOT of).
 
It would also be nice to have DDP (Disc Description Protocol) tools, and the ability to export DDP files for mastering houses.




There’s also a few features that I already like and wouldn’t want to see taken OUT.
 

Sonar is one of the few DAWs on the market that has implementation for the Mackie C4 protocols (including the C4 Pro).  I have one, and use it heavily, and would like to keep its functionality intact. Similarly, I use a Mackie Control Universal and Extender (the original dark grey models for each), and the implementation is imperfect, but suitable for my needs.Similarly, I use a Mackie Control Universal and Extender (all units are the original dark grey versions), and while the implementation is not flawless, it's very solid (and probably one of the better implementations for the DAWs that I'm familiar with).  While I'd prefer if the units had compatibility maintained and upgraded to accomodate newer features (e.g., Pro Channel), I'm also concerned that upgrading the control surface features for OTHER devices (which seems to be a trend in this thread) might break the MCU implementation, which is a crucial part of my current workflow in Sonar.