David Baay

A few thoughts: First, I agree that there is really no better way of approaching the arranging process, except that it might be simpler to use lanes of one track for the different sections of the original guitar part, rather than different tracks. Second, you might want to consider getting the timinng locked in first so that you can then copy tempo changes when duplicating sections, rather than having to map the tempo multiple times. While Melodyne and Cakewalk's own Audiosnap tempo mapping features can be helpful. I still find that manual tempo mapping using Set Measure/Beat At Now is more flexible, more precise, and ultimately doesn't take much more time (and possibly less) vs. all the massaging of tracks that may necessary to get the 'automatic' process to deliver the desired result. And, yes, once you have a good tempo map, you can 'smooth' or completely 'flatten' the tempo varations by enabling Audiosnap Clip Follows Project in Autostretch mode on the original track(s), and then adjusting or deleting the tempo changes that were needed to make the timeline follow the audio. If you're only going to add MIDI parts, it's easier to leave the tempo variation intact and quantize the MIDI to the variable tempo, but if you're going to record audio, it can be tough to follow someone else's tempo changes, and harder to tighten up the timing after the fact without introducing undesirable audio artifacts. That caveat applies to flattening the tempo of the original recording as described, but if it ends up being only one part in a multitrack mix, the artifacts will be masked to some extent, and it will making recording more parts with good timing much easier. I've posted many times about using Set Measure/Beat At Now to align the timeline to audio (or MIDI) on the old forum.cakewalk.com, and you can Google my old username, brundlefly, with 'SM/BAN' against site:forum.cakewalk.com to find them. It's pretty straightforward but there are some extra tricks for dealing with free-form or rubato intros, pick-up beats, rhythms that deliberately hit off the main quarter-note beat, etc.. This is the real world stuff that the automatic processes don't handle well. If you're interested in trying this, the best way for me to explain the process might be to share an example of what you're starting with, and I can map it (or part of it) for you, and tell you the steps I took.

Does it happen if you play the whole thing through from the start without interruption or looping? My first guess would be some plugin has unsynced randomness in realtime that does not occur (or occurs less frequently) with offline rendering. You might try bypassing some FX to determine the culprit, and then Google for similar reports on the web at large or the vendor's forum for possible solutions. You migth also experiment with different ASIO buffer sizes, and see if maybe that's a factor. If you have a non-zero bouncebuffsizemsec= parameter value specified in AUD.INI that's different from your real-time buffer size, that might explain why the issue doesn't manifest when exporting.

Okay, so here's my best guess as to what's needed: By default, Cakewalk is set to 'Always Echo Current MIDI Track' so that when you play on your controller keyboard, you hear the soft synth assigned to the currently focused Simple Instrument track. But then that's the track that will be displayed in the Piano Roll, hiding others by default. So, to see one track in the PRV while you perform on another track, you have several options: 1. Click the Input Echo on the instrument trakc you want to hear to force Input Echo on even when the track is not focused. This will alow you to focus the drum trakc in the PRV, and still be able to hear the instrument your playing. 2. Show both tracks in the PRV together by Ctrl selecting their track numbers in the PRV tracks pane at the right. The unfocused drum notes will be grayed out but still visible so long as you havethe vertial zoom set correctly. Things get more complicated if you have a durm map on the drum track, but the concept is the same - keep from losing sight of the drum track's MIDI when the focus is elsewhere. 3. Open the drum track in a PRV, and lock the view so it doesn't change when the focus moves away. There are probably other options, but these come immediately to mind. I kind of like option 2 because it will let you see where your live input notes are landing relative to the existing drum notes as Cakewalk shows a 'confidence recording' preview of the new notes in red. Hope that helps, or at least sheds some light on concepts that are good to know in any case.

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. ?