David Baay

That works, too, but not every track is going to have a dedicated bus where you can do that. And if the track has any post-fader sends, you're generally going to want the level of the track to be right at the output. Offset mode is the quick, easy and recommended way. of doing this. Incidentally, you can tell you're in offset mode because all the widgets will have a '+' in them. But it's easy to overlook in the heat of battle which is why users sometimes get in trouble by inadvertently enabling Offset mode (more so when 'O' was the default shortcut).

In the distant past, the PRV would sometimes get in odd states depending on where it was opened - .i.e. docked, undocked but not floating, or floated. You might try playing with that. Also I'd be curious whether this is all projects or just your current one.

You need to select the Autostretch mode from the drop-down next to Clip Follows Project before enabling it.

The track you use as a guide track for Fit to Improvisation is sacrificial. Its timing will go out of sync with the timeline and existing MIDI and Audio to which you're trying to align the timeline with tempo changes. If you want to keep a copy that stays in sync, copy it to another track or to another lane in the same track before executing Fit.

Hey, no fair, and where's the fun in that? The (unwritten) rules of the forum say you have to figure stuff out without being able to look at the project directly. ;^)

I cannot repro this. Since you're not recording, record options should not have a bearing. I thought the status of Non-Destructive MIDI Editing might, so i changed that, but still could not reproduce the problem. If you can reproduce it a second time, you might need to share exact steps. When you did the 3x drag-copy of the 'base' pattern was that also done in the PRV with looping already encompassing the 4 x 4 bars (if I'm reading the PRV interpreting correctly with the timeline out of view), or did you do that part in the Track View? And what's in the apparently empty clips?

Okay, my second guess is that you're exporting 'Entire Mix', and you have a send of that track (or the first bus it hits) to a second hardware out (maybe via another bus), like a headphone mix. What you hear in your monitors is only the master bus coming through the main outs, but what you get on export is a mix of the main outs and that other hardware output. Try exporting with Source=Buses, and select only the Master bus. EDIT: Hmmm... just looked back at your screenshot and see you have only one stereo output. But I would still recommend you export only your Master bus.

Flanging/Phasing generally only occurs when two identical signals (both frequency and timbre) go out of phase. If you're adding MIDI instruments to a recording that used real instruments or other virtual instruments., that should not happen. If it did, we'd all be in a world of hurt all the time. But if Mark's shifting-tempo trick made whatever you were hearing go away, I guess that's all that matters.

Indeed it was Brundlefly. Not sure why the new forum defaulted to my real name, but I decided to just leave it. I figured my avatar would be recognized by the old-timers. ;^) All your points are well taken with one exception: System performance should not alter latency. Latency should always just be fixed based on config settings, plugin delays and hardware/firmware interface buffers, and if the limit of CPU performance is reached, the audio engine will drop out.

Ah, okay. I thought you were just trying to avoid having to open the PRV track pane, and I missed the part about using a keybinding.

In the mean time (and maybe indefinitely, given that Pick Tracks was deliberately removed from the PRV in favor of the track pane a long time ago)... Depending on your workflow, and the number of tracks you have to deal with, this could be a workaround or maybe even the preferred solution: Enable editing on all tracks in the PRV track pane by sweeping through all track numbers, enable Autofocus, then close it. All notes will display as 'ghosted except for the currently active/focused track. Clicking on any note will 'pick' that track and un-ghost all the notes. If you know you're only going to be needing to work on a subset of all tracks, you can Ctrl+click in the PRV track pane to enable just those tracks for editing to reduce the 'clutter' of ghosted notes. This should at least reduce the amount of time you need to have the track pane open.

This could be an issue if the OP is playing a direct-monitored hardware synth, but in any circumstance where the audio passes through or originates from the box, 25ms of Plugin Delay Compensation would make performing pretty uncomfortable. So I doubt that's a factor in this case. Also, just so the OP understands, not all plugins add latency. only those with internal 'lookahead' buffers to 'see what's coming' in order to do their processing (e.g. transient shapers, convolution reverbs, any linear phase FX), some compressors/limiters). Plugins that do this are generally classified as 'mastering' plugins that are not intended to be used in the 'tracking' phase of a project. Also, Cakewalk allows overriding delay compensation on input-monitored tracks so you can still record external sources without feeling the extra latency in some cases. But, as John says, it's best to avoid tracking with plugins that need PDC.

See Timing Offset (msec) under Preferences > Audio> Sync and Caching. it's indented under the Full Chase Lock option which makes it look like it's somehow dependent on that option but it's not, This setting is primarily intended to let you advance the playback of existing MIDI driving external hardware synths to make up for the MIDI transmission and audio latency that would otherwise cause them to sound late vs. recorded audio and soft synth tracks. But because it works by effectively shifting the M:B:T against the audio clock (including the audio metronome), it can also compensate for MIDI latency on recording. The only problem is that the offset needed to correct for late recording (i.e. shifting the M:B:T grid later vs. the audio clock so the MIDI lands earlier in the grid) is the opposite of what is needed to compensate for latency on playback (shifting the M:B:T grid earlier so MIDI output is sent before audio). This isn't a problem if you don't use hardware synths because soft synths are handled like recorded audio, and aren't affected. Only I/O from/to hardware MIDI ports is affected. All that said, if your MIDI is being laid down 25ms late, you've got some systemic or procedural issue that needs to be addressed. One-way MIDI transmission delays are typically on the order of 2-3ms, and should not really be an issue so long as your audio latency is also low . I have seen a number of reports over the years of MIDI being lad down late (or sometimes early, which is really strange) on some hardware setup. Unfortunately, I've seldom seen this get resolved without changing some hardware. You can try experimenting with the Timing Offset, but values of more than a few milliseconds can start to have weird effects when starting/stopping playback and recording, It might be worth sharing you hardware setup, audio interface and driver settings, and letting us know what instruments you're using and how you're monitoring in case there's an obvious issue (like maybe using the MIDI metronome to get a click from an onboard soundcard synth).

Clicking anywhere in the track header will make it the active/focused track.

Depending on how you came up with 114.005, I would guess that the tempo is nominally 114bpm, even, and your measurement or the performance was just off by that much (on the order of 20 ticks or 10ms over a 4-minute song at that tempo). If we're talking about syncing MIDI to audio, that should be of no consequence unless the song is lot longer than that.

Actually, I generally feel the same way, and typically leave 'Always Echo' disabled. The main reason in my case is that I often leave Local Control enabled on my keyboard synth to eliminate the MIDI round-trip latency and get the best possible response when just playing and recording solo piano and not working with any other synths which is the way most of my projects start out. Obviously I don't want the MIDI track in my default template echoing automatically in that case. But when working in a project with multiple synth tracks, and wanting to have the most transparent experience with performing on a controller while switching tracks in the PRV, I would think 'Always Echo' is the way to go.

The currently focused track (name field highlighted) is the default destination for pasting. Selection and track focus are independent in Cakewalk so it's quite possible to select a clip in one track while some other track remains focused so the paste ends up going there. This is a useful feature when needed (e.g. you want to copy clips from several other tracks to the one you're currently working on without constantly having to switch the focus back to the destination track and/or scroll up and down in a big project), but it does mean you need to keep track (no pun intended) of where your focus is. If you're not deliberately intending to move/copy things across tracks you'll want to start all your edits by deliberately clicking in the header of the track you intend to work on to set the focus there before you do anything else. The PRV has 'Auto Focus' and 'Always Paste Copied Notes into Active Track' options to help with this, but so far as i know, the Track View still does not. This would might make a good feature request to facilitate some workflows.

To clarify, the PRV snap resolution and mode settings will override the global snap resolution and mode settings, but the PRV snap enable depends on global snap being enabled. So if you temporarily want snap completely disabled in order to draw controllers, you can just toggle global snap off with the default 'N' keybinding; you don't have to disable both.

And you wouldn't want that because...?

For the PRV, doesn't 'Always Echo Current MIDI Track' address the need in the most common case that you just want to be able to play the instrument on the track you're currently editing?

This looks similar to an issue i reported a long time ago (like 8 years!) that soloing a lane overrides clip muting. I was told this is expected behavior to facilitate auditioning a muted clip. I didn't really think that made sense at the time, but so be it. In my case, it affected playback as well as bounce/export. In any case, unless i missed it, your video never shows lanes. Any chance the lane of the muted clip is soloed?

You will want to identify one track to be used as the 'master' guide track (or possibly bounce two together - e.g. kick and snare - and use that), and 'Add to Pool' the markers from that track after ensuring they are locked to their respective beats. Then 'Apply' those markers to the other tracks so that they are all using the same reference for Clip Follows Project. With the markers all correctly locked to their respective beats, and shared across all clips, executing Clip Follows Project with the 'Beats' option should keep them all in sync and phase as they are stretched to fit the project. Merge and Lock markers can also be used, but I think applying a common set of markers from one 'master' track is clearer and less error-prone. To prevent phase errors, you should use the same algorithm on every track. It's best just to try them all, and see which gives the best result. Since I'm primarily a 'MIDI guy', I don't often have a need to stretch audio, but I've generally found that the generic Groove Clip algorithm often gives the most 'transparent' result, and the highly acclaimed Elastique Pro can sometimes grotesquely displace and/or distort a transient at particular location that ruins an otherwise good result. YMMV.

I briefly checked out the manual for this instrument, and it seems pretty straight forward - CC1 (Modulation)) switches between four articulations, but only for instruments in the '03 Short Tight' folder and the '04 Short Loose' folder that have short attacks. So if your trying to use CC1, you'll need to make sure you have an instrument loaded in that channel that supports it. CC11 (Expression) works as usual to control the volume of an instrument within a range limited by CC7 (Volume). This will work for all instruments, and is easy to hear, so I would suggested experimenting with that first as a sanity check, and then try CC1. If it's still not happing, it might help to see some screenshots of what you have set up, and maybe the Event List view of a MIDI track. It will also help to be using split MIDI and Synth audio tracks rather than Simple Instrument tracks so that you can clearly see MIDI events registering in the output meter of MIDI tracks, independent of the audio response.

Does the instrument UI have a modulation control? If so, does it move in response to the controllers? Do you have a 'forced' output channel assigned in the track header? If not, you'll need to make sure the controllers are on the same channel as the notes. I have no experience with EastWest instruments so don't know if anything special is required to configure controller response.

If you were already at that high MIDI Prepare Using buffer setting, you might actually want to try backing it down to the default of 50ms, and going up gradually from there. Another possibility would be that tempo and note position are interacting in a way that causes buffering to fail. I have not seen this since buffering was revised, and usually only with one particular note in a whole project, but it might be worth tweaking the position of a dropped note by a tick or two and seeing if it makes a difference or tweaking the nearest tempo value before a missed note (or for the the whole project if it's a fixed tempo.). I may not have the samples you are using, but I have Sampletank 4, and could give your a project spin on my system to see if it's platform-specific, and poke around for other possible causes if the problem reproduces. Bakers will probably need to do the same to understand what's going on. P.S. In thinking about this, I was reminded of an issue I encountered when I first got Sampletank that some instruments were not playing notes above a certain velocity because the channel-mapping of velocity layers in some patch definitions was screwed up. IIRC, IK responded to my post about it, and were going to fix them. Might have been specific to Syntronik patches though. The plain text patch files could be edited to fix the problem (putting all layers on channel 1), but there were too many so I only fixed the one I was using at the time.