David Baay

This is your problem. That's 35ms at 44.1kHz to get the sound out of the Minilogue through Cakewalk and back to your monitors. Most people would find that to be an 'unplayable' amount of latency for performing in real time on a keyboard. If it's not, it's because your monitoring directly or closer to directly than through Cakewalk. But you'll be performing to a metronome click, and recorded audio or soft synths that are late vs. the MIDI grid by the output latency, so your recorded MIDI will be laid down late, unless you use a Timing Offset to compensate. But even when your recorded MIDI is on the grid, the reponse of the external hardware synths is going to be delayed by the full round-trip latency, and sound late relative to the metronome and playback of existing audio that is only delayed by the output latency. Timing offset will allow you to compensate for these dalays either on playback or on recording, but not both, because the sync error is different depending on what you're doing. The bottom line is you need to get a harware interface with native ASIO drivers that can operate without pops/clicks/dropouts at a total round-trip latency down around 6-8ms (or less). I would think the Behringer should get close to that without Voicemeeter in the picture. I don't know much about it, but any layer of software you put in between Cakewalk and your interface's native ASIO drivers can only cause trouble.

1. You can change the selection range by directly dragging the start/end marker rather than setting the Now time and then using another shortcut to set From/Thru= Now 2. You can click and drag a time selection to a new start time, rather than having to re-select the same range somewhere else. That said, I've also be a little frustrated by having the selection marker cursor get in the way of clicking nearby to set the Now time. Two ways to deal with this other than de-selecting all are: 1. Enable Left/Right Click sets Now in track view options, and click in the clips view to set Now (loses selection). 2. Click in the very narrow section of the timeline below the scale where the selection cursor doesn't appear

One long ago fix for this with SONAR was to 'repersonalize' by holding Ctrl+Shift while launching.

Yes, if track gain and volume controls remain at 0dB, the input and output meters will initally show the same thing. But that doesn't generally last for long because the input level that gives you a good signal to noise ratio from your external sources, and a good input level for FX to behave nominally in the box, is probably too high a level to mix with other instuments. So the output volume is almost always going to be pulled down from what you recorded at some point, and unless you set the Playback meters to be pre-fader, they're going to reflect that.

I was responding to: I see now that "it" in that sentence is referring to the low input level, not the difference between input and output metering levels.

No, I meant it has no effect on the change that occurs when you switch between armed (record meters) and disarmed (playback meters). The input level at the interface will be that same either way. So something is happening inside Cakewalk to make the metering change.

Collapsing it doesn't completely close the view. If you undock it and close it, the check mark will clear. But you should probalby be able to close it by unchecking it in the menu, which isn't possible.

Setup of the DI box shouldn't affect what shows in your meters in SONAR when armed/disarmed. All that matters is the level at the interface input. Cakewalk will record that level regardless of any settings (unless the interface mixer applet is modifying it). And it will play back that level so long as no gain or volume changes are applied at any level (clip gain, track gain, FX I/O gain, track volume, bus gain/volume). A Pan law with -3dB/-6dB center can lower the playback level if you have mono interleave set on the track, but won't ever raise it. I recommend you start with the simplest possible record and playback configuration with input monitoring, making sure your record and playback metering settings are identical (except playback meters will probably be post-fader - fine so long as Volume fader is at unity). Then record single transient pulses and look at the numeric peak indicator as well as the meter while you make external/internal changes one at a time to see what effect each has.

As I said, you need to find and correct the root cause of this issue. Timing Offset is not the appropriate setting to address that. What audio and MIDI interfaces are you using, and are you using the audio metronome? If you're using ASIO driver mode, what is your Output latency shown in Driver Settings? Are there any PDC-inducing FX in the project?

OK. Well, the big difference between recording (and metering) from a hardware input, and playback from a recorded clip is that the Input Gain on the track affects only the latter. So I have to think the discrepancy is due to having the track Gain turned up (possibly in offset mode) to get the higher playback level.

Timing Offset should never have to be more than a few milliseconds. If it's big, it will cause issues because it shifts the MIDI grid against the audio clock, affecting both recording and playback. It's intended to compensate for small 3-5ms MIDI transmission/response latency of hardware synths, but if you're having to use it to compensate for MIDI being laid down in the wrong place when recording, you'll need to find a way to resolve that issue without using Timing Offset. If this is what I think it is, the MIDI recording timing issue seems to affect some hardware configurations. If your audio interface has MIDI ports on it, I would recommend you try to use those first, rather than separate usb ports on keyboards and sound modules.

I'm not understanding the routing at a glance. It wanted a bunch of hardware outputs assigned when I loaded it, and there was no way to know what was 'Master' bus. By default, the only thing going to my Main Out 1-2 ended up being the El Guitar track which outputs to a bus named A 1-2. But the project does drop out at 00:04:16:06 SMPTE, so it's not just your hardware setup. I can't spend any more time right now, but will go over the routing, and see if I can replicate it with a simpler project. EDIT: Cakewalk actually hung at the dropout in my case, and never came back. That's going to make stripping it down more difficult if it persists.

So a quick Google says Brainworx Ampeg VR is "exclusively for UAD-2 hardware and Apollo interfaces.". Since your interface is RME, I assume that means you have the UAD card...? I've never worked with one, but would guess that's where the discrepancy is being introduced, and would check the UAD setup.

Do you possibly have a non-zero Timing Offset entered under Preferences > Audio > Sync and Caching > Synchronization?

Are you arming the MIDI track or maybe depending on the preference setting to 'Allow MIDI recording without an armed track', which may have become disabled...?

Does that bus output to something other than Master, and/or do you change the output of the Aux to something other than Master? EDIT: In order to avoid creating a feedback path, Cakewalk automatically defaulted the output of the Aux to Main Outs instead of to the Master bus. But i still can't replicate the dropout.

Can you share that template? As noted in the other thread, I tried to repro this issue, and could not. Just curious what the full recipe is. You should formally report it to Cakewalk if you haven't already so they can fix it. https://help.cakewalk.com/hc/en-us/requests/new?ticket EDIT: I see you replied in the other thread, and the Aux send is from a Bus. I'll try that.

An extreme example to illustrate. Tempos doubled by the procedure outlined in my first post: Original Doubled

Suppose, as a simple example, you have a piece that's 100 bpm on the verses and jumps to 110 (110% of the verse tempo) on the choruses. Later you decide the whole thing is dragging, and you want to start at 120. In order to have the same relative increase in tempo on the choruses, you need to go to 110% of 120 = 132 bpm. If you don't maintain that proportionality, it won't sound right. This gets even more critical when you have a really rubato piece that's constantly changing tempo. As far the number of tempos goes, to accurately reproduce a tempo change across several notes that isn't linear, you need one change per note interval - no more and no less.

Since he's using the term 'create', I'm guessing maybe we're talking about drawing MIDI in the PRV...?

I don't really get what the issue is. Nudge does work in real time, and if you set successively larger multiples of samples for the three nudge values like 24, 48 and 96 samples (.5, 1 and 2ms at 48kHz), and take advantage of automatic keystroke repeating of the numkeys, it's pretty easy to nudge a clip back and forth while playing or looping by progressively finer amounts until you find the sweet spot. Maybe not quite as intuitive as a knob, but pretty easy.

The Mercury theme I use is the old original 'default' color scheme before the Themes feature was introduced. Now the default is 'Tungsten'. In the last relase of SONAR, Tungsten still had a PRV with a white background. It looks like that changed at some point. With the dark PRV background, selected notes get lighter to make them stand out, where they got darker in the old scheme. Since I don't use Tungsten, and can't confirm that the velocity tail highlighting matched the note highlighting before 19.09, but one way or another it looks like a problem with the theme definition. I also noticed that notes don't seem to be colorized by velocity in that theme as they are in the Mercury theme. Somebody who also uses the Tungsten theme regularly will need to weigh in. EDIT: Just looked again, and notes are colorized by velocity in Tungsten with the dark PRV, but they get darker at lower velocities - the opposite of Mercury. I never did lik the look of Tungsten. The 'wilted-pumpkin orange' highlights just never worked for me. ?

Yes. That's a very old bug. I thought it pre-dated x64 versions, but maybe not. You'll just have to use separate outputs and EQ in the output track. Personally, although I sometimes still grab TTS-1 for a particular sound that I think will work well for some purpose, I could live without it, and generally do. It always had quirks, doesn't have enough independent outputs, and most of the sounds are pretty weak. Some of the basses do sound pretty good, but so do Dim/Rapture Pro if you have one of those.

Not seeing that here; both selected note and velocity tail get darker as expected. In the first screenshot, the note is so light it looks like it might be muted. If you have a track with multiple lanes, and not set to Hide Muted Clips in the PRV, possibly your selected a muted note that is causing de-selection and masking of the an unmuted note in the same place...? If that doesn't explain it, you might need to give more details about track color, velocity colorization settings, etc. EDIT: Could also be related to the theme. I still use Mercury, so my PRV background is light, and note colorization for different states may be different.

Nice find, Chuck. I guess no one ever reported it to the Bakers. If they had, I'm sure it would have been squashed pretty quickly. EDIT: FWIW, I could not repro this in the current release with a new project started from the Basic template. Was able to record and playback out to 5+ minutes at 24-bit x 48kHz, 32-sample buffer with a send on that track to an archived Aux track with or without Input Echo enabled. Must be more to the recipe. Maybe multiple Aux tracks with echo disabled or with FX on them, or the project had to originate in an earlier version of CbB/SONAR when Aux tracks were in their infancy, or...?