David Baay

Okay, I take it back. I did a quick test, and it seems there is an issue here, and it goes back a long time (reproducible in SONAR 17.10). Guess I never noticed because count-in usually is disabled when recording existing MIDI. And even with it on, I typically run a much smaller buffer (32-64 samples) when tracking so the discrepancy is significantly less than MIDI transmission delay and there's no truncation of the recording, just slightly less delay.

What audio interface and driver mode are you using? The difference with count-in enabled is not normal; I'll double-check nothing has changed recently, but I've never seen this in any of my systems, and I use hardware synths in almost every project. You should still verify you have Timing Offset at 0, and maybe try disabling UseHardwareSamplePosition in Preferences > Audio > Config File (enabled by default). If the synth is a keyboard synth, you might also try recording simultaneous MIDI and Audio using Local Control to get another data point for understanding what's going on.

Ctrl+A to select the whole project, and then open the Audiosnap palette or the Audiosnap section of the Clips tab in the Inspector, and enable Follow Project in Autostretch mode. Then delete the unintended tempo change, and experiment with different stretching algotithms for different tracks to get the best result. Slowing down audio tends to create noticable artifacts then speeding up, but 2% shouldn't be too bad. Personally I might just live with the tempo change. If you didn't notice it immediately, it probably won't bother listeners, and might even add a useful sense of increased energy later in the song.

I've always been happy with Mercury, and don't often bother to check out other themes, but I do like this one - easy on the eyes with good contrast, and preserving the overall blue and gray nature of Mercury. Really nice job. I've been using it for a bit, and the only thing shortcoming I've noticed so far is that the dark shadow of a partial clip selection is a bt difficult to discern against the darker clip backgrounds. It would be preferable to have a lighter highlight that's maybe just a bit darker than the medium gray of a fully-selected clip. But I could get probably get used to it as-is

Try dragging and dropping the ADR project from file system (or the browser) into your working project. I did a quick test, and it didn't preserve folders or track colors, but it did preserve multiple clip groups. It also created a couple superfluous MIDI tracks (one named 'Matrix Data Track) which I seem to recall hearing about previously, but maybe wouldn't happen in a project with no MIDI. Not big deal to delete them, anyway.

Audio from a hardware synth is compensated for record latency just like audio from any other external source, but is not automatically compensated for MIDI transmission delay which is usually greater than audio latency, and will typically make it a bit late rather than early, unless... Check whether you have a non-Zero 'Timing Offset' (different from Manual Offset) under Preferences > Audio > Sync and Caching. Positive values delay the audio (including the metronome and playback of existing audio and soft synths) relative to MIDI grid, effectively causing audio from external hardware synths to be laid down earlier to compensate for MIDI transmission delay. The one other possible wrinkle would be if the synth audio is coming in via digital input, then it would overcompensated because there's no A/D conversion, but that's generally a much smaller delta (on the order of .5ms) than MIDI transmission delay.

That makes sense; MIDI files don't store I/O assignment information. As you probably know, CCs are easily transformed using Process > Find/Change. But you can also copy them directly from one controller lane to another in the controller pane of the PRV. You can even copy velocity to CC1, which is handy for GPO instruments that don't respond to velocity.

Hmmm... looks like they've changed their URL recently, but the link for the latency tester at the bottom of the page is not working for me: https://centrance.club/downloads/ If it doesn't work for you, either, PM me an e-mail address, and I can send you the utility. It's a standalone executable. No installation or licensing required. There are other ways of measuring actual latency, but the utility is quick and accurate.

Start by measuring the actual Round-Trip Latency, using the free CEntrance Latency Tester: https://centrance.com/downloads/ltu/ Then subtract the Total RTL reported in CbB from the CEntrance-measured RTL, and enter that as the Manual Offset. A positive value (the usual case) adds compensation to make up for the part of the actual latency that isn't being reported to CbB by the driver. A negative number subtracts from the automatic compensation in the somewhat unusual case that the driver-reported value is over-compensating. This will usually be less than 50 samples, so probably not a primary contributor to your issue, but it's a good thing to do in any case.

MIDI port assignments can get messed if your USB MIDI devices aren't powered up before booting and/or launching Cakewalk or if they're moved to a different port on your PC. MIDI channel assignments should be stable. Whatever you do, when a project comes up out of whack, don't re-save it. Close without saving, and make sure all devices are present and accounted for in MIDI preferences. If that's not it, you'll need to give a more detailed description of the problem, when it happens, and what hardware is involved.

The tempo needs changing? Or the start position of the clip is off by a fixed amount? What interface and driver mode? If it's a fixed offset of samples/milliseconds, and you're using ASIO driver mode, you probably just need to enter a Manual Offset in Preference > Audio > Driver Settings to acount fo un-reported 'hidden' latency in the interface (not to be confused to 'Timing Offset' for MIDI in Preference > Audio > Sync and Caching). If it's a whole measure, it's probably due to a problem with how Cakewalk reads sample position from the interface when metronome count-in enabled. This seems to happen with some interfaces. Often rebooting will fix it, but I've heard of cases where it's persistent. You might try a different driver mode. If it's actually that the tempo of the recording drifts steadily away from the click over time... I dunno. That would be very unusual.

Got the same result about 30 minutes ago. No confirmation e-mail from either Paypal or Soundspot, so I think nothing went through.

FWIW, V-Vocal is also launching fine and working nominally here in CbB under Win10 though I never use it.

If the PC is new, high specs alone don't guarantee smooth audio streaming. Have you checked DPC latency and done the basic tweaks to prevent CPU throttling and DPC spikes (Disable SpeedStep, C-States, Bluetooth and WiFi adapters in BIOS and set Power Managment to High Performance)?

Are you maybe using a project template or copied project that has reduced input gain to the track left over from some previous project? Input gain doesn't affect live input, which could explain playback being weaker.