David Baay

Sonar's using ASIO while Windows will be using WASAPI; it's not uncommon for the different driver modes to present I/O ports differently. FWIW, I bought a used Ultralite mk3 a year or so ago. It was cosmetically in mint condition but I had to return it because the USB port (or its connection to the board) was mechanically flaky and would disconnect whenever the cable moved.

I am able to repro the lock-up in a simple project with one audio track and one Instrument track and in a new project from the Basic template. I use Go to Time frequently and it works as expected when executed directly with the G shortcut. When executed via the Assist feature, Sonar minimizes to the Taskbar and when brought back to the foreground will not respond to the mouse or keyboard, including trying to close it; it has to be killed in Task Manager. I checked other "Go to" functions and they worked okay so it's not affecting all transport functions as I thought it might be.

FWIW, the original response from Jonesey missed the point that bouncing the clip before stretching resolved the issue; it wasn't about online vs. offline rendering quality after stretching. The actual explanation is that stretching individual clips doesn't ensure the waveform at transitions between clips remains continuous; the phase and/or level at the ends of each clip can change indepndently, creating a discontinuity that produce a click/pop. In order for the stretching algorithm to produce a contiguous waveform at it has to be processing a single file. Bouncing before stretching renders crossfades and merges the multiple cropped files into a single file so they're all processed together rather than individually.

Perfectly safe and fairly common. Just move the entire Projects directory in one go with Sonar shut down. After restarting, go to Folder Locations in the File section of Preferences and change the path for Project Files. The greates drawback to this is that the Created/Modified dates of all the folders will change to the date and time you make the move. If that matters to you, there are 3rd-party file management tools that can preserve the timestamps Note that it's also possible to move whole program directories and things like Cakewalk Content and sample libraries to another drive and create a symblic link from the old location to the new one using mklink at an administrator command prompt: mklink /d "C:\Program Files\Cakewalk Projects" "D:\Program Files\Cakewalk Projects" Any reference made to the original location in the registry or by Cakewalk installers will automatically and transparently be referred to the new location with no performance impact. If the new drive is faster, performance can even be improved. I did this on my old desktop DAW when I installed an SSD in it and didn't want to bother migrating the whole C Drive and OS to it. I just individually moved projects, program directories, plugins, samples and the global Audio Data and PIcture Cache folders to it and created symbolic links as necessary. Works completely seamlessly.

John's okay; he just has early onset old codger.

Your dyslexia is getting the better of you; It's FXB: An FXP files stores a single Preset. FXB files store a Bank of presets.

A quick Google indicates that a number of DAWs have native FLAC support and that the CPU usage to decode in real time is negligable compared to the load from plugin processing.

Good one. I guess you have Windows set to Hide Extensions...? I've been disabling that from the day it showed up in Windows 95.

Too many permutations. The result will differ depending on: 1. The project is new and unsaved so it's using the global Audio Data folder. 2. The project has been saved so it's using a per-project Audio folder. 2. Always Copy is checked/unchecked in Preferences 4. Always Copy is checked/unchecked in the import dialog. 5. Copy All Audio is checked/unchecked in the Save dialog Since the OP was referring to the global Audio Data folder, I tested by importing to an unsaved project. Always Copy was enabled in Preferences, but i overrode it by unchecking it in the Import dialog. This left the clip referencing the original 48kHz, 24-bit audio in the folder from which it was 'imported' both before and after saving the project with Copy All Audio unchecked. If the sample rate and bit depth (and possibly other file-type/format parameters) are matching what Sonar needs, the 'import' will be near instantaneous because it's just creating a link to the existing location and generating a waveform picture. If it does any processing to bring the file in, there's some sort of file format mismatch - maybe something other than sample rate and bit depth. EDIT: @bertox Double-check the value for Import Bit Depth under Preferences > File > Audio Data. This can be different from Playback bit depth shown as Audio Driver Bit Depth in Preferences > Driver Settings.

I think it's pretty standard in the industry to give new versions of synths a new plugin UID. This helps distinguish them and keeps the sound of an existing project from changing when the sound of the new version changes. But this also means that the DAW has no way of recognizing that they're essentially the same and doing an automatic substitution when you do want that. For the OP's situation (which most of us have probably encountered at one time or another) it would be nice if Sonar provided an option with Replace Synth that tried to apply the patch parameters from the replaced synth to the new one, but this could get tricky if the synth parameters are no longer the same or a user tries to do it with completely unrelated synths. As an example, Pianoteq tends to change its sound pretty dramatically with every major release, so you wouldn't want an automatic substitution to happen in a finished mix. The one time they made a big change in sound with a minor release (8.3) and no change in UID, they ended up having to provide users a way of loading the original v8.0 sounds to address this.

I'm not seeing that when the sample rate and bit depth match the project. If I check Associated Audio Files immediately after importing, it's referencing the path to the existing file and that persists when I save the projectso long as the Copy option in the Save dialog is also unchecked.

I did read it. I've now checked CbB on my old laptop and my main desktop DAW. Both are Win11 but the desktop was only recently migrated from Win10 . CbB and Sonar's Performance Meters behave identically with a new Basic project on both machines with the Audio Metronome enabled - Audio Processing: 1-3%, Engine Load: 0.1-0.2%. The only way to get 0% is to set the Metronome to MIDI Bottom line: Pretty clearly something is configured differently in Sonar on your machine, possibly something not obvious like the ThreadSchedulingModel in Config File (AUDINI). There have been a couple other cases of CbB tweaks not working well in Sonar. If you made any changes the default config in Sonar as a matter of course without checking before and after results, you should start reverting them one by one and watch for changes.

Yes, you're right about that. I was re-opening existing projects that have the button unlit and assumed they had always been that way becasue the lanes were never shown. I may never have noticed they're lit until close out completely and come back later. I actually don't pay that much attention or care that much about the state of the button. If i need to show lanes I click it. 🤪 That said, consistency is always helpful.

This isn't completely accurate. If you record or sequence MIDI in a new track the Take Lanes button will not show activated until you show lanes. But if you drag/paste MIDI to a track, this automatically activates the Take Lanes button. This has been discussed many times over the years. My feeling has always been that the indicator should only be lit if a track has more than one lane.

I didn't understand from your original post that you were talking about Remote Control. Remote Control does not allow specifying an Input port as tracks do so naturally it's going to pass everything. And Remote Control messages aren' routed through a MIDI track; the connection between Remote Control and a specified synth parameter is direct. Changing any of this will require a feature request, and the implementation would need to include an option to preserve the current behavior because many users will be depending on the current functionality that doesn't require any routing configuration. No, it shouldn't. There are many scenarios in which I want a track to record but not echo input - e.g. recording MIDI from a keyboard synth while using Local Control to trigger the synth.

As others have indicated, Mute and Echo only affect the output of the track and Sonar doesn't care whether you can hear output from a synth; it will still record incoming MIDI regardless. The only thing that would prevent that is if the assigned input channel doesn't match the transmit channel of the controller. Not sure how this relates, but there's no obstacle to that. Each VSTi precsents a dedicated virtual MIDI port to the DAW and each port's channels are independent of the others, just like hardware ports.

It depends on the driver and the state of the Sonar project. Many simply won't allow it while Sonar has control. Others will signal that the rate has changed, and Sonar will either complain about a mismatch if the project has recorded audio in it or tell you it's switching the project rate to match the device if the project is all live synths. In any case, when the two get out of sync, I'm inclined to blame the driver for allowing its rate to be changed without properly signaling that to the app that's using it or not responding to the app's request to change rates.

So are you still questioning why you see a slight load? As I said, I see no difference in Audio Processing or Engine Load between CbB and Sonar, and Platinum only showed the lower Audio Processing number that you might be used to. It was never zero with the Audio Metronome enabled in any release.

I haven't used it for a long time, but Ripple Edit was introduced partly because Insert Time/Measures by itself would not consistently move everything as expected.

Sample rate mismatch. 48/44.1 is inbetween a half and a whole tone. Make sure your interface's sample rate is matching Sonar. This won't usually happen if the interface is dedicated to Sonar using ASIO. If it's onboard audio and/or it's the default device for Windows audio, this is more likely to happen.

You have Metronone set to Use MIDI? If it's set to Use Audio, the plugin that drives it will be active and using CPU.

In Sonar the plug-in-powered audio metronome causes a 3-4% Engine Load on my laptop. SONAR Platinum, which used a less 'critical' load-measurement algorithm, shows only a tenth of a percent. I don't have CbB on this machine to check. I believe it used the same performance measurement algorithm as Sonar so should show the same idle load with the audio metronome enabled. If not, this might be something the Bakers should invetigate. I'll check my other machines that do have CbB. EDIT: I verified Sonar and CbB show roughly the same numbers on my desktop DAW: Audio Processing: 0.1 to 0.2% Engine Load : 1.5-2.5% And Platinum only shows the Audio Processing measurement at about the same level. Switching the Metronome to MIDI zeros the load in all of them.

The better approach would be to Undo and enable Ripple Edit All before inserting/moving; tempo/meter changes, automation, markers, etc. will all move together.

By "v17", I presume you mean the last release of SONAR Platinum, 2017.10. In any case, the new Sonar will install to its own subdirectory of Cakewalk, just sharing plugin and utility directories with old SONAR which will remain independent and run just the same so you won't have to migrate projects if they don't open and run the same or better in Sonar, though they absolutely should. Different users have had more or less success embracing the 'flatter' look and theming/colors/contrast of the new scaleable UI. Aside from that, I think Sonar is inarguably superior to SONAR in features, performance and stability. Very few users have had any issue running old projects in Sonar. The only other potential issu I can think of is that the sizing of various view and panes, track/lane heights and plugin UIs may change, depending on your specific display scaling, but that's fairly easily corrected on a per-project basis, or globally if you use Workspaces. Bottom line: It will take some time to get used to all the changes and get all your preferences synced up, but it won't 'break' anything and you can transition gradually. And you can try the free tier to start; it actually has very few feature omissions vs. the subscribed version,

Support for GS Wavetable was deliberately removed some time ago for compatibility reasons. I subsequently discovered a that it's still available if you set MIDI driver mode in Preferences to UWP instead of the default MME. But I can't say how long this workaround will persist, and I've seen flaky behavior using UWP mode with the one interface I have that supports it for hardware outs so I'm back to MME.