David Baay

You have to download it using Bandlab Assistant.

Yes, you can select the entire project with Ctrl+A. Then Ctrl+click on the box in the Audiosnap section of Clip Propertie in the Inspector to activatr it on all lcips. And then then use Ctl+click again to change the stretch mode and algorithm on all clips at once.

Not to continue too far off-topic, but just having a soft synth in the rack will force the project to use the Audio clock. Same with enabing the audio metronome. You cannot set the clock to Internal and have it stick unless nothing in the project depends on the Audio clock.

That's the typical experience for other CW users, too. It's especially unusual that this issue has persisted across multiple platform. As suggested, anti-virsu seems a likely candidate. I only ever experienced something like this when windows Defender's Real-time Scanning mode became spontaneously enabled by a Windows Update with no directories excluded.. Another thing to try would be to rename your AUD.INI file (or use the button in Preferences > Config File to Reset Defaults). And definitely get rid of any 3d-party drivers like ASIO4All and Steinberg's 'Generic Low Latency ASIO Driver' installed by Cubase. BTW, CbB is technically no longer supported on Win 7 or 8.1 although I know there are a significant number of users still on 7 with no issues.

This is corrrect. The inability to change sample rate after the fact only applies to projects with clips referencing recorded/rendered/imported audio files. Technically "MIDI-only" refers to a completely audio-free project (no soft synths, no active audio tracks, and MIDI metronome), using the 'Internal' system clock for MIDI timing with MIDI tracks driving direct-monitored hardware synths (or onboard 'Wavetable' synth), but it's often used to refer to any project that doesn't contain audio clips as John is in this case. FWIW, the last time I tried it, CbB wouldn't actually run a true MIDI-only project with clock set to Internal; the transport wouldn't budge.

Make sure the mode is Autostretch before enabling Clip Follows Project and set the Online rendering algorithm to 'Groove'. I've found the Elastique algorithms can get weird in certain situations, especially with percussive/rhythmic parts. I've only ever reproduced a progressive loop sync error like that once, and it was so slight (samples per iteration) that it took hundreds of iterations to get to a 20ms delay.

I'm not aware of any change in this regard. It's always been necessary to proactively restrict MIDI/Instrument track Inputs to the particular port and channel you want a track to record/echo any time you potentially have input from more than one port or channel, whether hardware or virtual. I learned this early on as my first MIDI controller (1988!) sent MIDI on two channels by default.

Yes, I've reported in the past that the 'confidence recording' indication on MIDI tracks shows all MIDI input whether the channel and port are matching the Input setting or not. It's not a big deal for me since I don't often use MIDI-generating plugins, but it's not ideal.

ROTFLMAO! Check my forum history, both here and on the old forum, and ask anyone who's been around here for a while about my ability to tease meaning from inadequate problem descriptions and solve problems. Also note that Mark acknowledged and fixed this issue only after I clarified how to reproduce it. In any case, you needn't worry yourself about my compreshension as I won't be reading or responding to any more of your posts. Cheers, Dave

Oh, no, here we go again... I meant the project setup and actions that produce "nudge are slightly off by a few .0 milliseconds in its jump". BTW, I just did a quick test, and did find it's not possible to nudge back to time zero, specifically, after nudging later from there. This actually rings a slight bell as having been reported previously. I'd have to search. Works as expected anywhere else in the timeline.

There are three indepedent nudge amount settings; numkeys 1,3 nudge left and right by the Nudge 1 amount; numkeys 4,6 do the same for the Nudge 2 amount, and numkeys 7,9 for the Nudge 3 amount. The setting of Nudge 3 amount should have no bearing on the behavior of numkeys 1 and 3 unless the default shortcuts have been changed. Need more details on the setup for your secondary question. I've never encountered an issue with left/right nudges not offsetting each other as expected.

You should start a new thread and clarify symptoms of "the WAV content is not loaded in the project.". If it's just a graphical issue with the clip not showing a waveform, you might just need to Recompute Pictures. If you're getting an error that the file is not found on opening the project, that's probably not specific to freezing but just indicating that the project file was moved or copied to a new location without bringing wave files along, and you need to locate them as prompted.

I see what the OP is getting at now. If you create a MIDI clip by drawing in the PRV, the take lane button remains in the 'no lanes' state until you expand it once, and then there's no way to get back to the orginal state while keeping the clip, I would say it's actually unexpected and inconsistent that creating a clip by drawing does not 'activate' the take lane button like recording, drag-and-drop, copy-paste, etc, do. The correct behavior would be for the button to be activated whenever there's any content in the track, no matter how it's created.

Try Ctrl+Tab to bring it to the foreground.

Undo is working for me to restore an empty track to its 'virgin' state with no take lanes indicated. But I usually do just delete the empty lane when that happens.

Two thumbs up from another piano player/composer. Lovely chord voicings, changes, pacing and ambience. I'd look at lowering/compressing the velocity range to tame the energy in the piano harmonics, especially where you're grabbing a big handful of mid-high notes. The piano tone sounds great in general, though. What is it?

Hi Lynn, I've been ignoring the songs forum for quite a while (makes me feel guilty for not posting anything myself recently), but happened to check this out. I really like it overall - interesting composition, good lyrics, singing, instrumentation, mix, etc. - but I'm surprised to see no one else mentioning... the timing seems a bit wonky (the technical term). Is it just me? As far as I can tell, the individual tracks have pretty solid timing internally, but the sync between them seems off - beyond anything I would consider to fall within the realm of "playing behind the beat" or "syncopation". It's actually hard to decide which part to use as a reference - maybe it's just that some of the percussion is ahead of the beat or has too much 'swing'? I think I'd have to be able to solo tracks and see where everything is relative to the grid to figure it out. I do like it a lot otherwise, so please take this as a constructive.

Yes, definitely a defect. You can send a report to support@cakewalk.com.

That's the fun part! ;^)

I can reproduce that selecting between the markers reports the wrong selection length by up to several seconds for a 30-second clip with matching markers locked to SMPTE when random tempo changes are added. But selecting the clip continues to report the correct time. And export was actually the correct 30-second length even when selection was made between the markers and the time was mis-reported at 26:26.

I figured as much. Otherwise I might have proposed you work around it by re-triggering within 16 measures on loud transients in other parts of the mix to mask it. The notes wouldn't be shown properly tied, but at least the Staff View wouldn't be showing nothing.

I guarantee this is due to the Bitbridge issue described above - acknowledged by the Bakers long ago but never committed to be fixed due to the increasing 'un-necessity' of using 32-bit plugins and the availability of work-arounds.

Acoustic bleed is the most likely explanation but there are audio interfaces with poor separation of I/O signal paths in their analog setions that can cause this as well, especially with the high-energy transients of a metronome click.

More specifically regarding 32-bit synths, there is a bug in Bitbridge that adds an empty buffer of audio to the start of rendered audio, causing it to play back delayed. This can be mitigated by running a very small buffer when rendering offline. Or, knowing that rendered audio is exactly one buffer late, you can slip-edit the buffer off the clip and slide it earlier by that amount. Beyond that, the relatively inexpensive 3rd-party Jbridge add-in does not have this issue, but may not be worth it unless you have a favorite go-to sound in a synth that has never been updated to 64-bit.