Sergei Pilin

Why? He's talking about the track colors. I'm talking about the general interface colors.

More contrast needed, look how immediately much more readable and easier on the eyes the whole thing becomes with just one simple slider move in Photoshop

Although the vectors in Sonar are probably simple SVGs which isn't hard to customize if there was a theme editor, what I believe he rather means is customizing just color themes leaving vector graphic elements alone. Would be a huge thing in itself considering the current uneditable color choices are subpar.

Point taken. The vinegar is there because I do care, been a Cakewalk user since 90s. It's just painful to see where it's going _compared_ to the free Cakewalk we've already have. The Cakewalk is the honey, but they want now money for vinegar.

All tastes are different, I completely agree. But there are things of preference (I've seen themes with green text on fire red BG and the guy was proud of it and had no troubles working with it), and then there are BASICS. The clips in the track view are one of the most important things (if not the) to work with in a DAW. Now look at the track view clips of the most used DAWs on the market on my screenshot, and then a light and dark theme of the same in Sonar. How anyone in his right mind could decide that clearly seeing clips in the track view is not important? It's not the matter of taste, it's a matter of professional incompetence.

And while we're at it, you've already reduced enough contrast making various BGs a shade of grey, that sure is easier on the eyes than pure white BG. But don't reduce it further by making dark text a shade of grey too, make it BLACK, don't be afraid of black text. Readability is the priority, not some hipster choice of shades of grey so it doesn't distract from whatever. Readability.

This whole thing is a disaster, why there's a random black window in a light theme?The person responsible for UI colors clearly has no any clue about UI design. Please give us back the customizable colors and stop torturing that UI guy

I guess it's these ones, black on darkest grey. The harder to read, the more improvement there is, it looks like.

It does however it's basically unusable due to extremely low contrast. For some reason they think a light theme means everything is a shade of light to the point it's unreadable. It is easy on the eyes though if you don't need to work with it and just prefer to stare at nice pastel colors.

I would join this request but on the contrary I need light menus everywhere. This only means we need our fully customizable UI colors back asap, BandLab's attempts at providing universally accepted color schemes keep failing, some color decisions are beyond any sensible design guidelines.

I did try to edit them in the registry to no avail, nothing changes unfortunately. They're most likely hard coded and the ones in the registry are just nonfunctional leftovers from the good old times.

100% agree with all this. Readability should be the first priority, "nice design" choices are distant second. The current color and design choices are as if they don't want to distract users with text and numbers making them as unnoticeable as possible. If they don't have decent designers then just make all the colors editable as in the older Cakewalk. And please, PLEASE, keep things consistent - if a user chooses light colored themes don't force them to have random dark elements such as this horrid black menu and dark themed Articulations and Export dialogues. Ones chooses a light theme for a reason.

Here it is. Spire instance test.zip

Just tested the same 54 Spire instances project with ASIO (96 samples) - Cakewalk wouldn't play it without crackles despite much faster computer, started removing track by track and the crackling stopped when I had 38 tracks. Amazing how low latency ASIO is so much more demanding than WASAPI. Sonar DOES play the original 54 copy project with no crackles! Although one more copy and it starts craclking too. So credits where credits are due - Sonar IS much more efficient than Cakewalk with low buffer ASIO. P.S. Replicated this project in Reaper, stopped at 104 tracks which still were playing with no problems. Now that is some optimized engine

Okay, will do and report. It's RME Babyface with my faster computer where I use ASIO and record stuff. The previous test was using the in-built laptop's Realtek sound, thus WASAPI

I just did just that - Instance of a Spire synth playing 6 note chord with 6 voice unison. Added Fab filter EQ with some adjustments, Valhalla delay and Lexicon random hall. Then started duplicating this track until it started to crackle then removed one more track just to be safe - 54 tracks on some modest 6 years old 4 core laptop in Bandlab! Wow, that's some power we have nowadays! Opened this project in Sonar and it totally crapped out with cracks galore. Started removing tack by track, it sort of stopped crackling at 44 tracks but all sounded wrong as if the polyphony was reduced. Didn't want to find out what was up with the polyphony since it was obvious Bandlab TONS more efficient that Sonar anyway. Both programs have identical config settings and use WASAPI shared. I could try it with ASIO too but kind of lost interest since it's obvious for me that I don't want to trade that much of performance.

I did have one channel visible with the spectrum analyzer, I turned it off and it didn't make much difference but it got me thinking - I tried to get rid of everything that was moving on screen - Piano roll, track view, everything that was animated on the Control bar, leaving just Console view so the only moving things were a couple of channel levels. It easily shaved off some ~20% of CPU usage (40 vs 33 in the Task Manager) which was much closer to Bandlab usage, so I guess most of the CPU usage difference comes from the new vector gfx overhead, mystery solved.

I simply look at the Task manager with the same project running. Where Bandlab uses 30% Sonar uses 40%. Where Bandlab is one/two plug-in away from start crackling, Sonar is already crackling. So when I see in the changes "we made several performance improvements to the audio engine to improve CPU use" I wonder under what circumstances these improvements become apparent, maybe you need some Threadripper 24 threads CPU and the 10 threads one I have are not enough to see the improvement. Right now what I see is a perfomance downgrade compared to Bandland on _my particlual computers_.

Hello, A question to those who has directly compared performance of the new Sonar after the newest performance enhancements with Bandlab and has found Sonar is faster/snappier/etc. The reason I'm asking is under all circumstances with all different projects I've tried on two different computers with ASIO and WASAPI, Bandlab _always_ uses less CPU for the same projects and allows more plugins until it starts to crackle. I'm just wondering under what conditions these enhancements become visible.

A probably not hard to implement feature request: right now we have adjustable time delay for MIDI tracks in ticks, there were numerous requests to make it possible to also adjust it in milliseconds and the developers replied that it was not that simple and pretty hard to implement, that's understandable since they sure know better, plus there's now the articulations adjustable both in ticks and ms. But! Why not add an option to simply _display_ this time delay in ms while still adjusting in ticks, taking in account the current tempo? It will be all irregular numbers like 2.416 ms and you won't be able to set it to be exactly 2 ms, but you would still get an idea of the actual delay in ms.

This is so obvious thing to add, not sure how many times I've instinctively clicked there expecting the full EQ to show up, to no avail.

I do know work arounds but they all are less than optimal when you constantly add/remove notes so you need to keep track of what has already been shortened and what needs to be shortened manually again. I think it's a fair request to be able to separate in time the note on/off messages automatically if needed.

Please consider adding a global MIDI option to shorten all midi notes by a few ticks so "note on" and "note off" don't have the same timestamp when the notes are connected. I believe Cubase has this. Those messages having the same timestamp is giving problems with Halion's Megatrig module (used in almost every patch) in the way that connected notes are simply won't sound.

All settings are the same, but you're right, it maybe because there's lots of debugging code inside which will be later removed. My system is very similar to yours too, looks like.

For some reason the performance has been actually downgraded with Sonar taking significantly more CPU here compared to CW, in every project I've tried, from 10% up to 80% depending on the project.