David Baay

Utilities > Cakewalk Audio Finder Tool (CWAF) will also show you what files are used by which projects. It will likely show that all the clips in the Audio folder are in fact referenced by the project. Most likely there are tiny slivers of clips left over from deleting with incompete clip selections. Unfortunately those can be hard to find in a complex project. If you know which files should no longer be referenced by name, you can select each track/lane one at time, right-click and choose Associated Audio Files. If you see one of the 'unused' file names in the list, you can start searching that track/lane for it. If you do a partial selection of a track/lane - even an apparently empty region - you can right-click and choose to see Associated Audio Files and it will show if there's something there or more than the one file you expect. Since it's possible (though unintended) for clips to be layered on top of eachother in the same lane, you'll need to check regions with visible clips as well. Once you narrow down the area, you can zoom in and scroll around to find the troublemaker(s). If the problem involves layered clips, you might have to move 'known' clips to another lane temporarily to find hidden ones. I realize this is a pretty ugly solution, but it's the only way I can think of to track them down.

As noted, it's showing only a 240-sample RTL for a 256-sample buffer. That's just not possible. With no hardware latency, the I/O buffers alone will give you 512 samples round-trip latency. It's typical for hardware/firmware/drivers to add 200-400 samples to this. Your own video shows a reported RTL of 742 samples with a 256-sample buffer. That's likely missing the ADA converter latencies which will typically add another half to a full millisecond each way although some manufacturers are better about reporting everything to the DAW. I'm not sure why the RTL in the screenshot was initially so far off the mark. The 829-sample Reported figure mentioned later by the OP sounds more like it.

Yes, and that's more on the order of what I would expect for a 256-sample buffer on a USB interface. The Total Round Trip of 240 samples in your screenshot made no sense.

TTS-1 is a full 16-channel Multitimbral GM instrument. Like all GM instruments drums are on channel 10 by default. All other channels default to piano, but can be changed.

Sorry. Glanced to quickly; thought you were on the Audio Driver page. MME is correct for most MIDI interfaces. As mentioned, Manual Offset is on the Audio > Sync and Caching page. Easiest way to set it accurately is to download and run the free CEntrance Latency Tester with an audio cable patched between an input and an output on your interface. Then set Manual Offset as the Measured Latency minus Reported Total Round Trip. https://centrance.com/driverfolder/CE_LTU_37.zip

How did you go about that, exactly? So far as I know, SI Drums offers only a basic kit with no percussion or other sounds. It's not a General MIDI instrument. EDIT: TTS-1 offers a full GM drum kit, and there are many free drum synths available that will include at least some percussion.

That shows your Driver Mode is MME, an outdated protocol for PC audio. The Arturia should have native ASIO drivers. Change the mode to ASIO and see what you get. It should work much better overall and allow you to run a lower buffer size. Also, I would suggest you lower your MIDI Prepare Using buffer to 50ms. 500ms was the old default before the MIDI buffering code was revised. Values that high should not be necessary any more, and might actually cause issues.

Seems most likely an issue with the Korg as the the interface and CbB would not be aware in any way that a knob s being turned on the synth. Possibly the Korg is generating controller messages that are being received by the track and echoed back out to the Korg. Make sure the Input Echo button is disengaged (you might need to disable Always Echo Current MIDI Track in CbB Preferences) or configure the Korg not to send controller messages from its panel. Incidentally, I don't think it has any bearing on the current issue, but one oddity I see is that that your ASIO buffer is set to 256 samples (applicable each way, in and out), but the reported I/O latencies are much lower than that. This reported value comes from the driver and can never be smaller than the buffer size. That misreporting shouldn't matter in real time, but your record compensation is going to be way off without an appropriate Manual Offset entered in Sync and Caching.

I still think that's only if the selection is partial, and your have Slide over to Make Room set in Drag and Dorp options. And a selection always moves as a contiguous block; clips within the selection should never move relative to eachother. I don't disagree with that, but it should have worked as expected based on my experience. And I'd be really curious to see and understand the scenario in which it doesn't.

If you're using a synth that generates MIDI or echos input to a virtual MIDI OUT, you'll need to ensure that track inputs are set specifically to the port and channel your controller is on rather than All inputs/Omni. This is a best practice in any case.

I'm actually not sure what scenario Mark is describing. I use slide a lot, and have never seen that behavior when sliding an entire track or project, and can't reproduce it now. The only time I've seen anything like that is when moving/sliding a partial selection with Slide Over Old to Make Room set in Drag and Drop options which has always been buggy (later material sometimes moves later than necessary or actually moves earlier when you're moving something ahead of it later). But that's all moot if you're starting with Select All.

Those are all good points/suggestions, but if the OP started with Select All and the meter is contant, that should have worked as expected, at least with regard to clip start times. Would probably need to see the specific project first hand to understand if the result was due to user error, faulty expectations for the circumstances, or an actual bug.

Yes. In both cases, when the buttons are not lit/engaged, the underlying functions (PDC and FX processing) are working. When the buttons are lit/engaged, the normally working-by-default processes are bypassed/overridden.

Yes, by design for people without hardware; originally you wrote "people with hardware". That's what I was correcting

I think you mean for people with NO hardware MIDI devices connected.

Yes, the FX button also operates as a bypass/override. There has been a lot of virtual ink spilled over the arguably unintuitive and inconsistent labeling/lighting/functionality of these and other buttons in the Mix module. If we're lucky, the new Sonar will revise the iconography at least.

CbB is loading TTS-1 because the GM/GS Wavetable is not longer supported in CbB so its MIDI port is not available and you have no other hardware MIDI ports available. If you don't want to use TTS-1, you'll need to get an external hardware GM sound module or a multitimbral keyboard synth with a GM mode.

Yes, as the documentation shows, the button is to "Override" PDC on "live" (input-monitored) tracks. Note also that you can only override PDC on an input-monitored track if the PDC-inducing plugin is not on that track or in its path to the output.

Ooh, good one!

Most likely due to Inadvertent imbalance of the separate L-R level controls on the "Main Out" hardware bus in the Console (drag the splitter at the far right to the left if you don't see it). You can double-click to reset them, and then click the Lock button to keep them together. EDIT: I always recommend exporting just the Master bus, anyway, because having a send to a secondary hardware out for any reason (e.g. a headphone mix) will get you in trouble with the two outputs being merged with Entire Mix.

Quick-grouping should work with freeze buttons. Ctrl+A to select everything, then Ctrl+click a freeze button.

Did you re-install the MOBO Chipset drivers? I haven't built a system from scratch for quite a while so maybe Win10/11 take care of this for you, but it used to be SOP for a fresh O/S installation.

... And I'm going to glom on to every CbB-is-flaky-unintuitive-and-unpredictable thread and write "This Happens to Me Too!!! And what's more , it does this other entirely unrelated weird thing when I mis-use it instead of reading my mind and doing what I want rather than what it's designed and documented to do based on the change I made to Preferences and promptly forgot about".

Not sure why you want to have two identical lanes of notes, but the behavior you describe would only happen if the clips are Linked (as indicated by fine dotted lines around the perimeter) which may be your default for Editing > Drag and Drop in Preferences. Right-click one of them and choose Unlink > Independent.

The only way you get overlapping notes like that is by editing or bouncing. It's not possible to record overlapping notes in single take from a controller unless it's sending on multiple channels and you're not restricting the input channel. If they are the same duration and 100% overlapping I can see you wouldn't be able to avoid selecting both by lasso as the whole purpose of lasso is to select everything in the time and pitch range the lasso encompasses, regardless of whether it's visible or not. In any case, I don't think it's reasonable to expect the DAW to be accomodate a situation that you can only get into by user error, and I'd be very surprised if lasso works differently in some other DAW. EDIT: Ironically the "merge" feature being requested here would actually make this scenario of overlapping notes and the resulting editing challenges more likely.