David Baay

In what context? The cursor for the Smart tool changes depending on what it's hovering over in the UI. Some of the Smart tool cursors do look a bit different than in CbB. I'm too used to it to recall which ones or exactly how they changed, but nothing too radical.

You can also set LinkPFSendMute=True in Config File to have Pre-Fader sends muted along with their source tracks. My guess is you had changed the send to Pre-fader and when you deleted/restored it you got a default Post-fader send that is subject to muting.

The resetting of the patch would have set the "dirty" flag on the project, prompting the re-save. Sorry you had to learn the hard way: Never re-save a project that doesn't sound right or is otherwise in a bad state; always Save As or Save Copy As with a new name. Ultimately, I think responsibility for this issue probably lies with T-Force as I do not recall a report of any other synth behaving this way in Sonar. Another possibility occurs to me: If the MIDI is from a third-party - not something you recorded/sequenced yourself- it may contain Controller/Program Change/RPN/NRPN messages that are causing the reset.

The Create page should show .CWT template files from which new projects can be started. By default these are located in C:\Cakewalk Content\Sonar\Project Templates If the default files are present, check Preferences > File > Folder Locations to verify the path set for Project Templates. If the files are missing I can share a copy of the default set for you to paste in, but that would suggest some larger issue with the installation process (maybe folder permissions) that needs troubleshooting. EDIT: What happens if you just hit Ctrl+N?

Removing/Restoring power, by a switch if it has one or by disconnecting power or data cable if it's USB-powered. Sometimes you can also just go into Device Manager and disable/re-enable the driver. It can often save the time/trouble of rebooting, especially when you're having a really chronic problem or deliberately reproducing a crash to troubleshoot.

I know of it, but not details of that model. I have an H1n from a couple years ago that I have used only a handful of times to record acoustic piano via the mics. And I experimented using it as an audio interface for recording directly into Sonar just to see how that worked. It's been a while but I recall that it worked that way as well but not in a way that allowed input monitoring. Long-term you will want to look into getting a basic ASIO audio interface with built-in preamps and a mic or two to get the most our of Sonar and not be messing around with file transfers and syncing the project to audio recorded without a click. P.S. If you want to share the two original files from the H2n for download somewhere (or zip up the project folder with the two left-channel tracks already imported), I could set up the two mono tracks in a project with the stereoizer setup configured for you to experiment with.

Each track has an 'A' button to archive the track that basically tells Sonar not to process it when enabled. If you don't see them, set the Track Control Manager at the top of the track pane to 'All". It can be turned off an on any time the transport is not rolling with no permanent effect. What I'm thinking is that this will cause any initializaitonto be skipped for that track on opening the project which might help determine the cause of T-Force losing its patch settings.

The input to the H4n is probably stereo, but if you're going direct in with a cable from an electric guitar, that's going to be mono, and recorded on the left side of a stereo file. Sonar would import that as a stereo track by default, and the sound would be only in the left channel throughout the production unless you change the Interleave on the track to mono which would put it in the center, but you still woudn't be able to control the Pan position. The better way to handle this is to bounce the stereo track to Split Mono (see Tracks > Bounce to Track(s) options) and delete the flatline track from the right side. All mono tracks will continue to sound mono through a stereo bus unless processed by FX that specifically create a stereo image with differing left and right-channel information. Here is one technique for "stereoizing" a mono track that was recently re-surfaced: The alternative would be to record from the H4n's stereo mics near an amplifier(assuming both electric bass and guitar) in a room that isn't too lively. Or double-track the mono recordings, reproducing the timing and articulation as closely s possible (i.e. playing along with playback of the original tracks) and pan one left and one right. It might also be possilbe to just use the H4n as a pair of mics with a preamp to be recorded directly in a stereo track in Sonar via whatever you're using as an audio interface.

Copy and delete as Chaps suggested is one way. You can easily select all notes of a specific note number(s) to be deleted by clicking/dragging in the keyboard/note names pane at the left of the Piano Roll View. You can also do a partial selection of the MIDI clip by this method, and then Shift-drag from the source clip to a new MIDI/Instrument track in the track view. Shift ensures the timing is constrained.

Sounds like maybe a plugin on the Master bus has gone into demo mode due to the trial period or license expiring. Not sure what you mean by "freeze one card at a time".

I have occasionally had MIDI I/O stop working after a crash because the driver is left in a bad state and the interface needs to be reset by power-cycling.

What I'm seeing is that during playback the slip boundary moves in increments much smaller than the snap setting, but noticeable. It appears to be right about 7 times my current 128-sample buffer = 896 samples = 18.67ms at 48kHz. Kind of a weird increment, but it may be variable, and/or I may have measured incorrectly. In my workflow I don't do enough of this kind of editing during playback to have noticed whether this is new behavor or not. I don't have CbB on this machine but can check Platinum 17.10. @msmcleod EDIT: I'm not seeing this in Platinum. I can't be sure it's not due to some difference in settings but seems unlikely.

Check if the Steinberg Generic Low Latency ASIO Driver has been installed at some point and uninstall it if present. This has historically interfered with CW even when not actually in use.

Right-click and drag a rectangle around nodes with the Smart or Select tool. With clips, anything you touch with the laso will become entirely selected, but in an automation lane only the nodes inside the lasso will be selected.

This should not be a problem. I'm thinking possibly you separately Locked Data on the MIDI clips (not part of Freezing) which would prevent cutting but not copying.

I can't repro that, and can't think what might cause it. Are you drag-selecting with the Smart or Select tool or lassoing with right- click, and does it make a difference? No, unfortunately there is no vertical level snapping option for automation nodes. The only workaround I can think of is to put nodes with all the needed values in a dummy track, and copy/paste them.

So I can sort of understand that it imight not be delivered with any factory presets, but you can save your own, right? Are you doing that? Sonar should save and restore the state of the synth regardless but it sounds like the T-Force is not responding correctly to some initialization message it's getting at startup. Try this: - Get a project working correctly by launching Sonar from scratch. - Archive the T-Force track and File > Save Copy As with '- Archived' added to the title. - Verify the current project is still playing as expected. - Browse to the copy of the project, open it, and un-Archive the track. - Does it play the expected patch?

This sounds familiar from another thread not too long ago, but I'm not immediately finding it. I'm thinking it had something to do with the default time range or source when executing a simple export from the Export module without going through the Advanced dialog.

Looks like a simple oversight in the development of the vector UI. I'm no expert but my impression is that very little carries over automagically; the devs have to re-implement almost everything, feature by feature.

On the contrary, giving your DAW software exclusive control of the audio interface driver is the first thing you should do to avoid potential audio performance issues, and that you absolutely must do to avoid actual issues. For years system tweakers have been advising to disable onboard audio while I've always recommended to keep it active and set it as the default device for Windows, browsers and other generic multimedia apps so they keep their mitts off the ASIO driver. And the DAW should always be using a dedicated audio interface with a native ASIO driver for anything other than casual listening or short-term situations where onboard audio with WASAPI is the only option. And while I don't think a lot of system tweaks are necessary, disabling CPU-throttling functions like SpeedStep and C-States in BIOS and setting Power Management to Best Performance are essential as well as checking for low and stable DPC (Deferred Procedure Call) latency, and if it doesn't pass muster, additionally disabling Bluetooth and WiFi in BIOS until they're proven to not be contributing. Beyond that I recommend not doing a lot of system tweaks unless some issue persists, and then trying them one at time to ensure they're effective - and not actually detrimental - as many can be. The same goes for Sonar Config File (AUD.INI) tweaks. Don't change anything from default without testing to see the effect over time and in different conditions. And don't automatically change anything as a matter of course on a new machine just because it worked well on a previous one.

Global Read button in the Mix Module disabled...?

Before doing this, it's critical to change the Follow Option to Auto Stretch so that Audiosnap won't base stretching on where the measure/beat transient markers are; it will just stretch the whole clip evenly. Bouncing renders any Audiosnap stretching to a new audio file that will have transients re-detected and now in different locations. Re-stretching a previousy stretched and rendered clip is going to compound stretching artifacts. If you decide later on that you want something different, it's highly preferable to start over with a previously saved copy of the project that's referencing the original un-stretched audio files.

If it were me, I would strip everything out of a copy of the project except the relevant track and buses, and if the issue persists, save that to a new location leaving un-referenced audio behind, Zip up that project folder, share it via One Drive (or other sharing site), and send Sasor a link. If for some reason stripping down the project fixes the issue, then you'll need to go over the routing of the rest of the project. I often find that the process of preparing a simplified project to demo a bug for Support reveals that I overlooked/misunderstood something. 🙄

yes, I meant to say real-time bounce to MP3 could be a problem. I haven't tested it for a long time, but I recall it has come up as an issue in the past, and I was able to easily reproduce at the time. But this was admittedly a looooong time ago, maybe even pre-X1 era, and on re-reading it seems the OP was fast-bouncing to MP3.

Anything real-time will always use the rea;-time ASIO buffer size, and bouncing will also, ubless overridden but a non-zero Bounce Buffer setting. I have run mine at 20 for years. If theory some rendeirng operaiton might be more efficient iwth larger buffers, but the main reason I raised it is that some plugins (especially soft synths) can misbehave when fast-bouncing with a very small buffer like 64 samples which I often use in real-time because I need low latency for input monitoring and my projects are mostly light enough that I can get away with it. Fast-bounce direct to MP3 is not recommended because the encoding generally can't keep up with the rendering. It shouldn't crash but you can get failures and/or bad audio. EDIT: Mis-interpreted what the export mode was, and meant to say real-time bounce to MP3 could be a problem.