David Baay

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.

Please start a new thread.

I can repro that. Developers likely did not consider the possibility of drones that long when writing or testing the code. Staff View issues are hard to get addressed so you might just need to keep that new-found awareness in your back pocket for future reference.

Try changing Bounce Buffer Size (MS) (should be ms for miliseconds) from Playback to 20ms. Some plugins don't like fast bouncing with the typically small buffer used for playback. You might also expand the Mix and Render section, and uncheck 64-bit Engine; some plugins don't play nice with that, either.

As you noted, the button display does not change immediately. Last Touched operates in parallel with the default duration setting. The value in the button won't change until you actually touch an event that has a duration different from the default you have set. Another way to see that the hotkey is working is to check the dropdown and see that the check mark next to Last Touched is being toggled on and off.

Is the bass MIDI or audio? If MIDI, any chance it's being generate by a 32-bit synth plugin using Bitbridge? If audio, is Transient Shaper or other Plugin Delay-inducing plugin on the track? Automatic PDC should take care of it, but possibly you have something going on with PDC override being enabled. Are you exporitng in real time (a.k.a Online rendering) or with Fast Bounce (a.k.a. Offline rendering)?

Search "Last Touched" in the Global context; it's there.

Meaning playback stops before the end of the clip, or the clip ends before you stopped recording? Same place every time? A fraction of second early or a good part of a measure or more? Are you using a 'real' analog mic plugged into an interface or onboard PC sound or a USB mic?

- Import/snap the sample to start on a downbeat (1:01 if its a new, empty project). - If it's not at 1:01, snap the Now time to the Measure where you imported it, hit Shift+M to open Set Measure/Beat At Now, and OK to 'anchor' that starting point. - Count time while listening to playback and stop the transport just before a downbeat (e.g. 4 measures to 5:01 if starting from 1:01) - Tab to that transient, hit Shift+M, enter the Measure and Beat you counted to, and OK. - CbB will change the initial tempo (or the one you anchored) to make the timeline fit the clip and insert a matching one where you do the 'Set' (which you can delete if not needed as an 'anchor' for more 'Sets' further out). - If the calculated tempo is very close to a whole number, that's probably the actual tempo and you should Undo the 'Set' and just enter that tempo wherever the clip is starting.

You probably exported in stereo format. Importing directly from the project's audio folder is quicker and will ensure you get the original raw (and mono) recording.

Yes, it's at the bottom of the Draw Duration dropdown in the Tools module. But the module size has to be 'large' to access it (image URL insert not working for some reason): https://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Tools.20.html

It worked for me but source has to be Arranger Sections. If you were exporting clips as your workaround, it wouldn't work.

Something similar was reported quite a long time ago with Exclusive Solo in the PRV Track Pane. Probably the same root cause:

Yes, I use scroll wheel a lot.

Okay, I thought you were saying that toggling the Master bus interleave to mono and back was doing something to interleave of the source track. But the issue is that Bounce to Clip(s) is is forcing the plugin to output mono until the bypass is toggled. You might want to clarify that in the title, and put the step that triggers the unexpected behavior (Bounce to Clip(s) last. Yes, that seems buggy.

First be aware that MIDI track meters are always registering output regardless of whether the track is armed or not. So the only valid test of whether Input is working indpendent of Input Echo and output/metering/rendering is to try recording something. If recording works and playback works, then it's an Input Echo problem If nothing is recorded, some things to check: - The left-side (input) indicator in the MIDI Activity monitor that CbB places in the System Tray is responding to the controller. - The track Input is Omni (all channels) or to same channel as the controller is transmitting. - The track is armed and/or 'Allow MIDI Recording without an Armed Track' is enabled in MIDI Playback and Recording preferences. - The event types you're trying to record are checked in MIDI Playback and Recording preferences. The last two would affect recording but not live Input Echo so probably aren't a factor in any case.

Can't repro, but not sure how the various actions would be related and might be missing something. Does it really matter that the plugin is set full wet and the clip is bounced and the interleave on the Master is toggled to reproduce the issue? I went through the steps twice from scratch starting with the Basic template and the interleave on the track with the Sonitus Reverb is remaining mono as expected. in the first case, I started playback a few times at various points, and in the second case, I did all the steps without ever playing back.

The question is about the default Input assignment for a MIDI track (or the MIDI side of an Instrument track). The order of synths in the rack has no bearing on this. The way this works partly depends on the setting of 'Always Echo Current MIDI Track' in Preferences. If it's disabled, the default Input will be 'None'. If 'Always Echo...' is enabled or you manually enable Input Echo on a new track without first selecting an Input and there is more than one hardware and/or virtual MIDI input available, the track Input will default to All Inputs - Omni. The only way to get around this behavior is to use track or project templates as Greg suggested. Bottom line: No, there is no option to set a default MIDI Input assignment for new tracks inserted without using a template. I don't know why this has never been implemented as it's been requested many times over the years (decades!). If a track template can do it, you would think a default template could easily be designated for inserting new tracks.