David Baay

I have Melodyne 4 Editor, and no stability issues currently. Last time I had a problem with freezing, it turned out to be an interoperability issue between certain VST3s and NVidia drivers; fixed by a driver update. Cakewalk Dev have a very good and close relationship with Melodyne, having been an early adopter of ARA, so there should be no finger-pointing. If it's reproducible by either of them, they will get it fixed, but more likely you have some system-specific issue. Ideally, you will be able to provide detailed steps on how to repro the issue in the simplest possible project, started from the ' Basic' template. If it's only reproducible in a specific project, strip it down as much as possible without losing the reproducibility, and send them a copy of that project. Sometimes the process of stripping it down will identify the problem.

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. P.S. CEntrance has since made made the utility available again at this new URL: https://centrance.com/driverfolder/CE_LTU_37.zip

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. P.S. CEntrance has since made made the utility available again at this new URL: https://centrance.com/driverfolder/CE_LTU_37.zip

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.

Check Preferences > MIDI > Control Surfaces to see if keyboard controller ports might have been taken over due to a previously configured control surface being disconnected.

Hmmm... good one. Any chance you have inadvertently overlapping/duplicate note events causing phasy sound that manifests as a pitch shift? If not that, what happens if you deliberately insert Wheel events with a value of 0 before and through the note to hold the pitch constant?

The only other suggestion I have is to make sure you're inserting it in the synth rack, and not in the FX bin of an audio track. I've seen the symptoms like this when synths are inserted in FX bins. Cakewalk supports this configuration but it's not the preferred setup.

Well, seeing the IK sale coincidentally going on at the moment. I broke down, and actually purchased MODO bass. It's working fine here, but I did notice immediately that - like a lot of bass synths - it's programmed to sound an octave lower than standard keyboard tuning and doesn't play below the standard low E on an electric bass. So any notes below MIDI Note# 40 ( the second E up from the bottom of an 88-key controller) won't be heard. I haven't yet figured out whether the synth has a transposition option built in - didn't see one at a glance. Otherwise, it's all good here even at very low audio and MIDI buffer settings. EDIT: Spent some time getting up to speed with videos and playing around, and realized the transposition is necessary to make room for keyswitches. All in all a very cool and good-sounding instrument. I just love modeled stuff.

I can almost hear Spock's eyebrow going up. ;^) If MODO is fine in other DAWs, and Cakewalk is fine with other synths, the logical conclusion is that there's an interoperability issue between the two, but it's not possible to conclude that the issue is attributable solely to one or the other. It takes two to tango as they say. The first thing I would suggest is raising your MIDI Prepare Using Buffer. In SONAR the default was 250ms, which was too low for some synths/FX in some situations. Recently, the MIDI buffering process was re-engineered so that that buffer values are lower and more representative of what's actually going on. I believe the new default is 50ms, and the buffer is supposed to increase dynamically 'under the hood' as needed. But I wouldn't be surprised if that adaptation is still imperfect, and suggest you increase it manually. Try 100 or 200, and work down from there to see if you find a sweet spot. Also, if it has both VST2 and 3 flavors, you might try the alternate one. If that doesn't get it, I'll download the demo and see what I get. Have been meaning to do that, anyway. I'm pretty sure some others around here are using it without a problem, so there's hope it can work for you as well with the right configuration.

I usually zoom with Ctrl+Alt+Scroll Wheel, but just tried the buttons and cannot reproduce any issue. And I don't recall seeing any other reports of this. In order for the Bakers to fix whatever you're encountering, you'll need to give them a project and/or recipe that reproduces it consistently.

So a quick Google indicates the x32 includes a 32-channel USB audio interface. Dumb question, maybe, but since you're new to audio recording... Did you install drivers for that interface and record individually miced instruments to separate tracks in Cakewalk or did you just record a stereo mix via analog output from the x32 into the line input of your laptop?

Check the section of the keyboard manual on Auto Accompaniment.

You just need to be able to log in to Cakewalk Command Center, and you can re-install any legacy content. EDIT: I just checked, and the Nomad plugs are part of the Studio Mixing FX Suite under the SONAR branch (Platinum in my case).