David Baay

I can only repro that the output ports of the drum map get re-routed to the next available virtual synth port (in the order they were added to the project) while the virtual port of the synth being replaced is momentarily missing. This is not entirely surprising. It works okay if the synth being replaced is the last one inserted or the only one in the project. I'm not not seeing the unexpected freezing.

Ah, okay. So it's not really that "selection is cancelled", either; it's that the first lassoed node that goes offscreen is never included in the selection that's created when the mouse button is released.

Not sure why, but I cannot repro that. Can you repro in another project - maybe one without arranger sections?

Yes, this is something you would definitely want to try reproducing in the simplest possible project. If it turns out to be project-specific, it'll be difficult to get to the bottom of it without examining a copy of the project directly.

Yes there are situations that PDC override can't accommodate (e.g. having both recorded audio and live input on the same track or having a routing that takes the live input through the plugin that's adding the delay). But none of that is really applicable to the OP's issue since he's reporting over-compensation of recorded audio and that Manual Offset can't compensate for it neither of which should be affected by PDC override. One thing I'm wondering about is this: Is the headphone amp getting signal from an output on the same Presonus mixer/interface, and is it using ASIO driver mode? If using ASIO drive mode, you can use the CEntrance Latency Tester to measure the actual latency and calculate the exact Manual Offset as CEntrance Measured RTL minus CbB-Reported RTL. https://centrance.com/driverfolder/CE_LTU_37.zip

This quote from the ref, guide suggests that plugin delay is taken into account when compensating a recording and agrees with my experience. I think something else must be going on to cause the overcompensation the OP is describing. If anything, failure to take plugin delay into account would result in a late, under-compensated recording, and a positive manual offset would fix it. But I just double-checked and adding the notorious TS-64 Transient Shaper to a track did not affect the sample-accurate record compensation I have dialed in though the delay was there when not direct-monitoring the live input or engaging PDC override.

Yes, I'm familiar. I just didn't make the connection between "solo" and "mono".

I should have asked what was meant by ''solo" in your original post, but since volume and sustain controllers were reportedly not being chased, either, I thought the issue was more general.

Definitely need to get to the bottom of that. MME is not going to cut it, and WASAPI should work unless the onboard sound hardware is really ancient/atypical. Look for newer drivers as Mark suggested.

Given the OP is having an issue with crackles, I thought it best to recommend Exclusive mode. Troubleshooting 101 - remove variables that could be contributing to the problem and start with the configuration that has the best chance of success for the task at hand.

Yes, tell us what kind of numbers you're seeing. And what is the Performance Meter in Cakewalk and Windows Resource Monitor showing? What's in the project in the way of plugins? If you start disabling things do you find one in particular that's driving the load? What interface and driver mode? If it's onboard audio you should be using WASAPI Exclusive mode.

I verified this is all working as expected for sustain and volume controllers, and Zero controllers does not have any effect on CC7 Volume, anyway, so even if searchback/chase were not working the last volume in effect should persist after stop/start. And if the MIDI volume control in the track is enabled (no parens around it) that level will be sent every time playback starts unless it's overridden by some volume controller in the track.

I'm not familiar with it, but it appears Poise has a MIDI THRU function, and you need to go to the synth properties for Poise and disable MIDI OUT. Or set all other track inputs to something other than MIDI Omni as discussed. This is just how it works.

Hmmm... I'd have to check that. The name was originally "Controller Searchback" and was changed when Note Chase was added to be consistent with terminology commonly used in other DAWs. I have always understood that searchback/chase looks for all controller types and am pretty sure it works for Volume and Sustain.

Check your DPC Latency - a measure of how ready your CPU is to respond to requests from the audio driver to fill its buffer: https://www.resplendence.com/latencymon Common causes of high/spiking DPC latency are Bluetooth and WiFi drivers. If not needed, the hardware should be disabled in BIOS. While you're there, also make sure that CPU-throttling features like Speedstep and C-States are disabled. And make sure your Power Management profile is set to High Power.

It is enabled by default I believe. Preferences > Project > MIDI > Other Options

+1 on being able to lock the duration of a MIDI clip to absolute time, But in case you're not aware, 'Set Measure/Beat At Now' (Shift+M) does what you want - maintains absolute playback timing of MIDI while shifting the timeline around it with tempo changes. And it calculates the required tempo for you. The first track I lay down is almost always recorded without a click. The main reason I'd like to be able to lock a MIDI clip to absolute time is for the occasions when I inadvertently record into a project that already has tempo changes and need to delete them without altering the playback timing.

I had an issue loading some AAS VST3s that was related to their calls to OpenGL to render the GUI that was resolved by updating Nvidia drivers. Have not had a problem with any VST3 before or since.

Yes, every software instrument has a dedicated port so there's no need to differentiate channels unless the instrument is multitimbral and you actually want to use it that way. Even then, the events can still all be entered/recorded with the same channel, and you can use the forced output channel assignment on the track to re-channel them.

Hold Ctrl+Shift when changing the first port/channel and they will all change. Or Change one and hold Ctrl+Shift when changing another one to have that range changed.

I'm no expert on plugin technology, but my basic understanding is this: Every plugin has a Unique ID assigned (by registration with Steinberg, I believe). If it changes for any reason, the DAW will not recognize it as being same plugin. This is not a Cakewalk-specific issue. The UID will typically change if the new plugin is VST3 where the old one was VST2 or 64-bit vs. 32-bit, but may also change when the manufacturer adds capabilities to the new version and re-registers it as a new plugin because existing presets or parameter mappings are not compatible with the original implementation. The only real solution is to ensure you re-install the legacy versions of the plugins for compatibility with old projects. Since they have different UIDs, they should be able to coexist with the newer versions both in the O/S and in projects, but it's probably best to install them in chronological order if possible.

Those look like display artifacts to me. I sometimes see this, but only when zoomed far out (e.g. showing the full song length) on clips with fairly dense controller data. In my case, that's usually continuous sustain controllers on piano tracks where the controllers display as triangles at the bottom of the clip so would not be generating vertical lines in any case. There may be an interaction with specific displays or graphics controllers that makes it happen at different zoom levels on different machines. I've never looked into it that deeply as it's not an issue at the zoom levels I'm more typically working at with a minute or less of the timeline showing.

There is no such thing as a "clip file". An audio clip is a virtual object defined in the program that references an audio file on disk. Everything about that clip other than the raw sample content and some basic metadata that are part of the .WAV file definition is stored in the project file as an object property - name, start time, length, clip automation, fades, transient markers, etc. Two completely different projects can reference the same audio file in the same location on disk and have it start at different times in the project and have different non-destructive edits applied to it. In fact, this is exactly what happens when you save new versions of the same project in the same project folder with evolving edits over time. Nothing is written to audio files until you bounce and then a new file is written rather than overwriting the original.

Which would of course be the usual use case. Glad you got it figured. I just came here t post a link to the bug demo project I sent to the Bakers last year, but i guess it's not necessary now. Oh, wait, I guess it is. Here's a link to a project that shows the issue without sidechaining. See the Notes for a complete description. There were some other issues that are no longer reproducible in 22.02, but the delay compensation issue persists. https://1drv.ms/u/s!AvHuw7srYo1slQ4ZYAPxRQOH5Sea EDIT: I just brought this file into my laptop to verify the download and realized this .zip file has an old version of the bug demo project that does not have notes. Suffice it to say that if you zoom in, you will see that the clip in Track 1 had to be slid 140 samples late to make it null with the copy on Track 2 that is going through the upsampled Channel Tools. Note, also, that per-plugin upsampling enables are stored in the registry, not with the project, so Upsample on Playback/Render for Channel Tools has to be enabled on your system.

Yes, I think that's why it's not a good test of the Upsampling issue. With Upsampling alone, some delay is introduced but PDC is not invoked. Your test suggests that having some plugin in the project that's reporting delay to CbB causes PDC to be invoked, masking the problem with Upsampling, especially in the case that the plugin introduces more than 140 samples of delay which I suspect Transient Shaper does since the added latency is noticeable. I'll give it a try when I have some time.