David Baay

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.

I'm not exactly sure what you have going on because Sonar wouldn't allow sending or outputting the reverb bus back to any source track as that would create a feedback loop, but the Reverb bus should Output to Master. EDIT: I should add that when using an FX on a bus as a Send FX, the FX should be set to 100% wet. The dry signal gets to the Master directly from the track/bus that's the source of the Send, and the wet signal gets there from the FX bus. Dry/Wet mix is controlled by a combination of the send levels and the FX bus Volume.

Not in my experience. NDME overrides Blend and will force a new clip to be created.

No, becasue Blend does not alter any notes in the target clip as Replace and Move do.

I would think the stereoization of the (presumably) mono input from the guitar is happening at the output. So, you're recording a dual mono dry signal and it's getting stereoized on playback (and when monitoring, whether direct or via Input Echo) through the Helix. If the Helix doesn't offer an option to record from the output via internal loopback in the console app, you're going to have to setup a manual loopback.

Yes, I intended to mention that all the Melodyne (i.e. pitch correction) work should probably be done first since it's optimized for working on raw audio and might be negatively affected by any stretching artifacts introduced by Audiosnap. And it should (and must) be rendered before Audiosnap can be enabled.

It's always better to let your audio guide your project tempo, recording the freely varying tempo that you want, and using the various methods available to fit the project timeline to it (Set Measure/Beat At Now being my prefered tool). But if you have an existing fixed-tempo recording that's matching the fixed tempo of the project and you want to add a tempo change after the fact, do the following: - With the audio clip(s) selected, expand the AudioSnap section of the Clip Properties tab in the Track Inspector. - Check the 'Enable' box. - Select 'Autostretch' from the 'Follow Options' pick list. - Check the box to enable 'Follow Proj Tempo'. The clip(s) will automatically conform to any tempo changes you make. See the documentation for information on stretching algorithms and using Bounce to Clip(s) to render the stretching permanent with an Offline algorithm. Although it's all reversible, even after you render the stretching, it's generally advisable to work with a copy of the project to facilitate recovering the original state in case things don't go as expected for any reason.

Maybe. I was actually anticipating Noel and the gang might get some financing together to buy the IP and give it a go without all the corporate overhead. It's hard to imagine Gibson wouldn't have found someone to do that at some point, but it might not have turned out as well as it has if not for Ming's deep pockets. I'm distinctly part of the old guard when it comes to what I see as valuble features and glaring omissions in a DAW. I try not to push back too hard on what others want to see added/changed, and I think I mostly succeed. But I've always been more tolerant of life's many imperfections than some, and often find it slightly amusing how vehement people can get about the small shortcomings that all DAWs have or even just simple implementation differences between them - not that this is the case here. I just can't get that excited about any of it one way or the other. And it's not just my age; it's who I've always been. For years, I've been happy to see what the Bakers would add to each new release without wanting for much, myself. I suppose a lot of it was driven by keeping up with other sequencers/DAWs and feature requests from users as much as the Bakers' own initiative, and I should be thankful for that; I never really thought about it that much.

Not everything unexpected is a defect that needs to be 'fixed'. 95% of the time I find this setting to be unnecessary, and it is disabled by default. Basically all it does is use slip-editing to 'mask' partial copies/moves/deletions instead of 'destructively' truncating clips and removing events. This is why you get the result you described, and why I suspected immediately that was the cause. I can't really envision a workflow scenario in which one would need to be going back and forth between the two modes often enough for it to be controllable with a shortcut. I suggest you leave it off for a significant amount of time and see if you really miss it. Having Sonar's behavior constantly change in different contexts due to toggling settings that are meant to be persistent is a recipe for confusion and inefficiency.

I think disabling Non-Destructive MIDI Editing under Preferences > Customization > Editing will resolve both those issues.

Glad to help. I was just now reading through the responses and getting ready to post the same solution. 😜