David Baay

I'd be interested in looking at any example of an exception to what I've explained. One way or another, if a MIDI file opens with notes starting somewhere other than 1:01:000, there must be some message or metadata in the file that defines an earlier starting point.

The timestamps of events in a MIDI file are not in M:B:T format; they're just total tick values starting from 0. If you open the file in Sonar (or any any MIDI app) the first event is always going to be at 1:01:000 and the M:B:T position of all the other events is derived from the PPQ clock rate and time signature(s) embedded in the file. If you want the musical events to start at some specific point later in the timeline, the only option is to have an event at 1:01:000, and include that in the export. Again, this is just how MIDI files work, and is not something that Sonar - or any DAW - can change. Audio files pretty much work the same way except that you have the option to export and import Broadcast waves which have an absolute SMPTE offset embedded in them. In the absence of that information, an audio file will just open with the first sample at time zero in the DAW/Player, and if you want the music to start later, the beginning of the file has to include "dead air" from time zero.

Okay, I misunderstood what you want. The above is correct, but the limitation is not Sonar; it's the Standard MIDI File format. If you want the file to start before the first note, there has to be some event to define that point. Another option is to insert a tempo 'change' at that point; it can have the same value as the initial tempo. Since the tempo map is included in the SMF file, including that tempo node in the time selection will define the start of the file.

Just select the time range in the timeline before exporting. If you have Start and End Markers, you can use those to define the selection by various methods.

I would not expect to see a significant load from any sane combination of native Prochannel plugins not including any 3rd party plugins in FX Chains. But I haven't run SONAR on an i5 since sometime in the early 2010s and the minumum recommended spec for Sonar is now 8 cores.

Glad to help. It's come up many times over the years and I've reported it as a bug more than once in the past but it seems to baked in to the way Sonar handles VSTi output channels.

Set LinkPFSendMute to True in Preferences > Audio > Configuration File

What's happening is that freezing actually adds 3dB to the level of mono synth tracks. This is a long-standing issue/quirk of SONAR/CbB/Sonar. This can be addressed either by changing the Interleave of mono tracks to stereo or changing the inputs to stereo before freezing.

So the click track it plays back in sync with other tracks and the live playback metronome, and only the export is out of sync? Like Erik, I would want to know whether the sync error is a fixed offset or a drift or...?

Yes, maybe, but like most design choices it has benefits in terms of the flexibility of the result - e.g being able to bounce/export all your tracks (or buses as stems) in one go for mixing by a 3rd party I'm would guess the Bakers are aware that some other DAWs do it differently, and simply felt the logic and flexibility of their approach is ultimately superior even if it requires a little extra understanding /forethought on the part of users. Also, once a certain design logic has been in place for years or decades, they risk upsetting the long-time user base by changing it.

Visibility of these was eliminated some time ago due to compatibility issues. My understanding was that this had to do with Win11 but that seems not the entire story as some apps continue to work with them in Win11 as you've observed. In any case, the one workaround I am aware of is that setting the Driver mode to UWP under Preferences > MIDI > Playback and Recordiing to UWP made the GS Wavetable available in Sonar on my system. UWP mode has always been flaky for me and I don't need the GS Wavetable so I changed it back; this was just an incidental discovery. YMMV and I can't promise this workaround will persist.

Sounds like your activation has expired and is not renewable. I haven't been keeping track of CbB deadlines, but IIRC October 1 was the last opportunity to reactivate. While the project is still open you can retrieve copies of the recorded WAV files from the project's audio folder or from the global Audio Data folder if it's a new project from template that was never saved.

Bouncing with Source = Tracks generates a separate bounce for each selected track. In that scenario you will get the first track bounced to the track you created (and presumably selected as the Destination), and the second track bounced either to the next existing audio track below that one or to a new track created by Sonar. In order to merge two or more tracks you need to bounce with Source = Buses and select a bus that they're both/all outputting through.

Running the transport should reset any delay compensation to 0 if all plugins are disabled, but try enabling the PDC [override] button in the mix module. This will eliminate PDC on the track you're input monitoring so long as there isn't a PDC-inducing plugin active on that track or in its path to the hardware out. If you still have latency, it's probably not due to plugin delay.

A stereo track will effectively have the two channels panned hard left and right. Recording them to individual mono tracks will have them both center-panned. Depending on the degree of correlation betwene the two channels, the mono setup is going to produce up to a 6dB increase in level at the Master bus, potentially clipping the output, unless you pan the mono tracks hard left and right to match what a stereo track does. This is a possibility, but I recall that issue being addressed some years ago, and can't repro the problem now.

Inspector is showing Peak only, and Console is showing Peak + RMS. Incidentally, thanks for alerting me to the release of Pianoteq 9, I was just on their site a week ago to check and miseed it by a few days. @msmcleod I can repro the OP's screenshot showing that the lowest meter segment in one channel of the Console meter in Peak + RMS mode sometimes stays lit indefinitely after playback is stopped. I used Pianoteq 9, like the OP, and have not confimed with other VSTs or pure Audio tracks.

The warning will also be triggered by clips that have Audiosnap enabled but haven't actually been stretched. But the 'Select All Audiosnap/Slipstretched' option ignores unstretched clips. In that case, the only way to know if a clip is in that state is to select one at a time and check the Audiosnap section of Clip Properties or the status of the Enable button in the Audiosnap Palette. I would agree with Mark that the better option is to just save as CWZ or Zip the folder in Windows Explorer to preserve all the non-destructive stretching until you're fully ready to commit all the edits.

Yes, and Delete Hole notoriously will not work in an empty area of the project; there has to be some clip selected. It was the shortcomings of Delete Hole plus issues with the 'Move Over to Make Room' option for drag and drop that drove to the implementation of Ripple Editing.

Okay, but then you get to answer all the threads on the forum like: "I accidentally recorded a bad/duplicate MIDI take into an existing clip and it's too late to undo; how do I fix this, and why isn't there a big red flashing light warning me my takes will be merged?" 😉

I think what the OP is encountering is that those buttons are not available in the small version of the transport module. Keyboard shortcuts are the answer; I almost never touch the transport controls. I would guess that's a limitation of the MP3 file architecture.

I think "first export" basically means "if there isn't already a preview file". So if you delete all preview files, it will automatically create one on the next export. And it's been previously determined that bouncing any track in a project that doesn't yet have a preview will also generate one. My projects often have two preview files, one with a shorter name than the other; I'm not sure what that's about. If a project folder contains multiple versions of a project there may be additional project-specific preview files. Both the implementation and the documentation could use some refinement.

I believe the documentation I linked clarifies that an initial preview file is created on the first export regardless of whether the box is checked or not.

Unless you're using the same interface as the OP, you should start your own thread. As posted earlier, this experience is not typical. It may well be an interoperability issue with your interface driver or some plugin, but that doesnt mean Sonar alone is at fault. In particular, it's not uncommon for a plugin-specific issue to be exposed in one DAW and not another, and DAW developers often have to make special accomodations for improperly/atypically coded plugins. Also it's well-known that the way Sonar initializes drivers at startup is not compatible with virtual ASIO driver aggregators like ASIO4ALL and Steinberg's Generic Low Latency ASIO Driver.

These files are created and used by the Project Preview function: https://legacy.cakewalk.com/Documentation?product=CakewalkSonar&language=3&help=NewFeatures.14.html I do think the Bakers should add some options to manage when these are created/updated and how long they are.

No, I checked; disabling zero controllers did not help. And the MIDI was my own - only note messages.