brundlefly

Using the Mercury Classic theme in Sonar, I find some things have better contrast than CbB and some are worse. My main issue is with the text in dialog boxes where the font is so fine it appears grayed out. I've reported this to the Bakers and I can only suggest that you report your specific issues as there is very little that can be controlled at this point other than choosing from the pre-defined color schemes/themes.

Is this because you're manually interacting with the synth UI while recording, or you just don't like Fast Bounce? Are you also exporting in real time? As I said, if that's the case, it's likely some interoperability issue with the driver is causing the crash, and doing a Fast bounce/export should avoid it because it doesn't involve the audio driver. I mentioned TTS-1 because you wrote "CBB virtual instrument" which I interpreted as meaning something bundled with it, and TTS-1 is the only instrument I know of that regularly causes crashes.

The PC modules definitely need more work, and I'm confidant they'll get it. These are the kinds of specific, actionable suggestions I'm talking about, and I've raised a number of them myself.

If a project has a preview file, a triangular Play button will be displayed when you hover of the project's thumbnail.

Those are Project Preview files that can be played from the Start Screen without opening the project. They will survive Clean Audio, but can be deleted manually without causing any missing audio warning on re-launching the project. Sonar automatically creates them when you export to file and if you export something other than the Master bus or Entire Mix, the preview will reflect that. So far as I know you cannot currently disable this function globally, but there is a checkbox in the export dialog to disable it and I believe that will choice will persist on a per-project basis. I'm hoping/expecting that eventually there will be more control over this feature, including the ability to limit the length of preview files to conserve space.

We heard you the first two times, and you need to start letting it go because 'it is what it is' to a great extent. Harrison and UAD notwithstanding (and both pretty minor players in the DAW space by my reckoning), the broader industry trend is still generally toward flatter, simpler graphics. The good news is that I can assure you that you'll get over it more quickly than you think. Your screenshot clearly shows how much sharper Sonar's vector graphics are. If you try to go back to CbB after working with Sonar for a while, you'll find it looks fuzzy and feels overly 'busy' in comparison. That's not to say there isn't room for improvement, and I encourage you to make specific suggestions about possible improvements to contrast, legibility, consistency, usability etc. Many such suggestion have already been implemented. Continuing to just generally bash the new graphics as "childish" is not helpful and won't change the overall direction that the UI is taking.

Try removing the Steinberg 'Generic Low Latency ASIO Driver' from HKEY_LOCAL_MACHINE\SOFTWARE\ASIO I understand the UR24C is a Steinberg product, but preumably it has a dedicated ASIO driver other than the 'Generic' one that Cubase installs and that's what you have selected in Audio Devices...? That Generic driver has been known to cause issues with Cakewalk, specifically; I don't know why.

Meaning buses are also unselectable? The only way I can reproduce that behavior is by selecting a track that's outputting to a dead-end Patch Point that isn't connected to anything downstream.

I have zero reservations about recommending Sonar precisely because it installs in parallel with CbB and does not interfere at all with continuing to use CbB. The guts of the program and project file architecture remain largely unchanged and projects can currently be migrated both ways without any issues that I know of.

So what instrument are you freezing? If it's TTS-1 which is a DXi and has proven to be less than perfectly stable for some users, try a VSTi. Did you try a non-real-time bounce and/or alternative real-time buffer sizes? If fast bounce works, the real-time problem is something to do with your audio interface driver. Have you rebooted at some point since updating? I understand the problem seems related to updating, but AFAIK no one else is experiencing anything like this so it seems unlikely that's the only factor. Maybe share a simple project for others to test and see if it reproduces on different hardware.

Have you ever had CbB or some other DAW software working consistently on your current platform, and is it a laptop or desktop? The only time I've had the transport and meters moving without producing output, and it wasn't due to some routing/state issue in the project, it was due to the interface driver getting into a bad state and needing to be re-initialized by power-cycling. If it's happening consistently with two interfaces, that would suggest either some 3rd-party application/driver is interfering or there's a more general issue with USB comms/power/sleep recovery, etc. on your system. I started having problems something like this a while ago on my laptop and eventually determined the USB port was intermittently losing contact at the connector. Swapping cables didn't help and I ultimately had to move it to a USB-C port that didn't have as much wear and tear on it. If those interfaces are currently bus-powered and have the option to use external DC input, you might want to try that.

No recording when everything else is working would most often be due to having inadvertently enabled Punch in a region outside where the transport is. No playback audio could be a lot of things. Is this with audio tracks or MIDI through virtual instruments? Are track and bus meters active when this happens, and you've verified the Master bus output assigned to the correct audio output driver. Do either of the interfaces have output meters, and are they active?

In the mean time, change the Source Category to Buses, and select only the Master bus. I would also suggest disabling Render in Real-time unless you really have need to hear the bounce or some plugin is misbehaving when fast-bouncing. Otherwise, there is no quality difference between fast (a.k.a. offline) and real-time (a.k.a. online) rendering.

What VSTi and is the MIDI your own or some 3rd-party content? What's your ASIO buffer size and do you have a non-zero value set for BounceBufSizeMsec in Preferences > Audio > Config File? Reverting AUD.INI should have defaulted it back to zero which tells CbB to use the realtime ASIO buffer size for offline rendering. If the realtime buffer is very small or very large, it can cause problems for some plug-ins. Post a screenshot of your bounce/export dialog right before OK.

How are you focusing the target? Are you clicking in the tracks pane of the Track View or of the PRV or something else? In general, I like to do track-to-track moves/copies in the track view, but I understand it might be easiar to make a partial selection in the PRV and change focus without leaving it. Ths advantage of doing it in the track view is that you can select the source material, move focus to the target track, and then cut/paste in one go without doing anything in between. Also, I recommend binding a keyboard shortcut for 'Go to From' (was F7 by default before SONAR X1, and that's still what I use). Then all you have to do after making your selection is hit the shortcut to set the Now time. Your method should work, but the extra steps make it more error-prone as well as time-consuming.

More likely a particular plugin is heavily loading a single thread or some combination of plugins can't be effectively load-balanced due to their location in the project. https://legacy.cakewalk.com/Documentation?product=SONAR&language=3&help=AudioPerformance.14.html Cakewalk have been optimizing multi-threading and plug-in load-balancing as long as anyone in the business. If you can document a particular plugin or combination of plugins that disproportionately loads the first core in CbB/Sonar compared to some other DAW with an identically structured project. I'm sure the Bakers would want look into that.

Just writing mixed-case 'Sonar' should be enough to distinguish the new product from the all-caps SONAR of yore, but I've been adding 'new' in some cases just to make it clear.

Based on the Ref. Guide saying it works this way in Cakewalk/Sonar/CbB over all these years, I think that must have been the intent initially but somebody dropped the ball. Not sure why it's been so hard to get traction on it. My main need for it has been that I SM/BAN a free-form MIDI recording and then either discover later that I made a mistake or decide to re-record it and forget to delete the tempo changes from the previous round. Currently there's no way to undo that other than recording it into another DAW at a fixed tempo without syncing them.

Debug code is excluded at compile time for all public releases, including Early Access builds. So far as I know there are no signifiicant differences between CbB and Sonar audio engines at this point, and I cannot detect any performance difference in terms of late buffers or reported Engine Load numbers. Meter and transport graphics animations have been optimized in Sonar so it 'feels' smoother, but there should be no audible difference.

I think you must be misremembering which beat you set. Sonar will not allow setting a beat at time zero because that's always 1:01:000 by definition. For a 4 beat (1-measure) clip you would need to set the now time where beat 5 should fall, and SM/BAN 2:01 to that time. It's not possible to know where to set the Now time in that case unless the end of the last MIDI event extends exactly to 5:01, so normally you would have needed to set Now tot he start time of the event at beat 4 to 1:04 to establish the correct initial tempo. Or you could listen to the clip playing back and stop the transport where 2:01 should be, and set 2:01 at that Now time. SM/BAN works by calculating the tempo needed to make the specified musical beat fall on the specified absolute Now time relative to 00:00:00:00 if there's only one initial tempo, or relative to the absolute time of the previous tempo if the tempo is variable, and changing that previous tempo make that happen. And it changes the start time and duration of MIDI events to preserve their absolute playback timing at that new tempo. I've requested this many times over the years decades. If SM/BAN can recalculate the durations, setting MIDI to Absolute time base should be able to do the same. The Ref . Guide actually still mis-states to this day that it does: "audio clips maintain their absolute (SMPTE) length, while a MIDI clip will follow the value in the Time Base field." In makiing my request I've always mentioned that the Ref. Guide needs to be corrected in the mean time.

I don't know. I easily got both Platinum and CbB into the double digits by repeatedly starting and immediately abandoning new projects. I've never paid much attention to the Untitled index so I can't otherwise say what it's done in the past. Possibly some shared component has been updated that affected all of them.

I checked CbB, and Platinum and they both increment the project number every time you create new one whether the previous one has been saved or discarded. The only difference is that New Sonar increments the number again when you exit the project because the Start Screen uses a 'hidden' project to play previews and creates a new one every time it opens. So the number effectively increments twice as fast. It only resets when you close Sonar.

You mean when pasting rather than when drag-copying? Clips will paste to the current Now time, and the Now cursor will follow the snap resolution when you click in the timeline. And if you use Ctrl+Alt+C to Paste Special, you have additional options to paste into existing clips, paste multiple copies, etc.

My understanding is that some higher-end Behringer interfaces do have a native ASIO driver whereas some like the UMC22 list ASIO4ALL in the downloads section.

The same reason you can't put 87 octane in a Ferrari - detonation. ;^)