David Baay

Malcom, you can click the Reset Configuration button under Preferences > Audio > Configuration File to get back to default configuration that should work... if audio configuration is the issue. I specifically suggested it for the OP since he said his X3 config was working, and Platinum should be able to use that same config. But it may not be right for you, depending on the driver mode you're running. If you haven't already, you should start a dedicated thread for your particular case, and let us know what hardware you're running with what audio settings.

Almost suggested checking channels, but most synths will respond to any channel. But a multitimbral synth might need to have a patch explicitly loaded for each channel used.

Back up CbB's AUD.INI, and copy X3's over it. If it solves the problem, compare the files.

What interface are you using for output? The onboard audio is showing muted in the system tray. Also the notes in the PRV are so light, they look like they might be muted (not the clip, but the individual notes). If so, select all, and click a note in the PRV with the mute tool to unmute. Other possibilities: Shift+T to show lanes, and make sure the lane isn't muted, and show the controller pane in the PRV and make sure the velocities are up.

Looks like the clip has some 'dead air' on the front end, and setting the tempo at 2:01 should not have been necessary. Try clip-editing the start of the clip to the first transient, drag it back to 1:01:000 and then drag it to the timeline. If you need it to start at 2:01, you can insert a measure with Ripple Edit All enabled to push the clip and the tempo changes out with it.

What about WASAPI Exclusive? I can't vouch for Cakewalk's performance in WASAPI Shared mode in an otherwise ideally configured environment because I've never used it that way. When I wanted to see what WASAPI was capable of at low buffer sizes, I ran it in Exclusive mode. In fact, IIRC, the lowest buffer settings aren't even available in Shared mode...?

I can repro that. Same happens in the last release of Platinum, but it's probably using share utilities that have been updated by CbB.

For my part, there is no rushing to judgement. I'm just suggesting logical troubleshooting steps, including making changes to the Cakewalk configuration. The current release is working too well for too many users to conclude that the update has an inherent issue that's independent of the environment it's running in or the configuration of Cakewalk or project files. Of course the ultimate troubleshooting step would be to roll back the update, but that isn't possible with the current installation model unless you've prepared in advance by backing up or using scook's utility for managing versions. I believe there were some changes to WASAPI driver mode related to sharing drivers, but the OP is using ASIO. I do see more dropouts on my laptop, but I attribute that to using WASAPI shared mode on a low-spec machine with years of accumulated software bloat (dual-core company Lenovo). And it's no worse in this release than it's ever been. It's fine if I only use it for playback with the buffer at 10-20ms, but down at 3ms where you would want it for real-time performance of soft synths or input monitoring , it's dropout city. But I can see the DPC spikes and CPU hits from other processes that cause it, and if I go out of my way to do a clean boot ith WIFI and Bluetooth disabled, and switch to WASAPI Exclusive mode, it's quite stable at 3ms. This reminds me... there was a problem with WASAPI driver mode at 44.1 kHz in a release late last year that I never encountered because I run at 48kHz. There's no indication that anything like that has resurfaced, but it might be worth changing sample rates (in a project with no recorded audio) as another general troubleshooting step, regardless of what driver mode you use.

How 'suitable'? IIRC, Latencymon labels anything under 1000-1500us (1-1.5ms) as 'suitable', though that's not ideal for a DAW that's running a buffer on the same order of magnitude. That said, moderately-high-but-stable (say 400-500) is better than usually-low-but-spiking (150 with spikes to 1000). And you need to let it run for a while to see if anything is causing spikes. Did you try the Config File reset?

The Octopre is a standalone pre-amp with no direct connection to the DAW, right? In that case you can only set Timing Masters to channels of the slaved 18i20. That's how I run my interface when slaving to an Alesis QSR (because the Alesis didn't like being a slave) . Works fine. The only limitation is that Cakewalk can't force a clock rate change when you load a project that includes audio recorded at a different clock rate.

The amount of RAM in the system should have no bearing on the performance at different buffer sizes. Usually the only time an ASIO buffer setting can be too high is if you're streaming a lot of recorded audio tracks/files on playback (or maybe recording many inputs simultaneously), and your Disk I/O buffer size is too low to keep up. But I can imagine some interface hardware/firmware/drivers might not be optimized to handle very larger buffers.

And, in case you're wondering, the change was deliberate to prevent inadvertently changing a parameter value for all tracks in a project with nothing selected - convenient for some, but dangerous for others.

Using the Smart tool, yes. But, as noted, it will only move one note of a selected group unless you hold Ctrl while clicking, and then release it while continuing to hold the click and then drag. Using the Select tool as suggested by tecknot works better if you're going to move a lot of notes. But since I pretty much exclusively use the Smart tool in other areas, I prefer not to have to change tools if I can help it. FWIW, I record all my MIDI in real time, and don't do a lot of note-by-note editing in most cases. When I do, the PRV suits me. But I would love to see the Staff View improved, nevertheless.

LatencyMon after 40 minutes of web browsing with ~30 tabs open in Chrome - including watching Geoff's video about it - while Cakewalk ran at 30-40% load in the background, looping the old 'These Arms' demo, which is pretty 'heavy', at 64 samples. Cakewalk Perf Monitor reported 1 buffer dropped... when I stopped playback. DPC latency typically runs under 100us on this machine if I disable WIFI. Off-the-shelf Dell i7 6700k with power management and CPU throttling disabled:

As I said, it may well be due to some incidental config change. But there can also be changes in the environment that affect a feature of Cakewalk that other DAWs don't have like plugin load balancing/upsampling, 64-bit double-precision engine , etc. Or this, which I believe is not enabled by default; possibly you did this...?: Experimental aggressive task scheduling model We continue to work on improving our multi-threaded engine performance and have added a new "aggressive" task scheduling model. The aggressive task scheduler utilizes more efficient task management that can result in better multi-processing and fewer thread context switches. This feature is still experimental so report back if you notice any improvements or problems when using it. The new scheduling model is activated by setting the ThreadSchedulingModel value to 3. This can be done via Edit > Preferences > Audio - Configuration File.

<begin lecture> While it's possible something directly related to the update precipitated the problem, I feel compelled to point out that since Cakewalk is updated every month, the last update is pretty much always "recent". And there have been numerous of users attibuting a problem to a Cakewalk update, and then eventually discovering something else changed in their system or Cakewalk or project configuration. Back when SONAR was updated anually, the incidence of 'was working fine until today' being reported randomly between updates was not significantly lower than it is now. Also, just because a performance issue isn't reproducible in another DAW doesn't rule out that the root of the problem is in the environment or a setting in Cakewalk that's been changed independently of an update. <end lecture> Since dropouts are very often related to DPC spikes, I would start by running a DPC latency check: https://www.resplendence.com/latencymon If that checks out, try clicking the Reset Config button under Preferences > Audio > Configuration File. Cakewalk will archive a backup of the current AUD.INI, and replace it with a default. If performance improves, you can compare the default to the backup to see what changed.

I figured... just had to throw that in. ;^) Glad to hear you got it worked out.

It's a bit surprising that your I/O latencies are more than twice the buffer size each way (i.e. lots of hardware/firmware/bus latency), but if audio file playback sounds okay I wouldn't be too concerned about that just now. I suggest you start by clicking the Reset Config button in Preferences > Audio > Config File. Cakewalk will build a default AUD.INI, and back up the existing one. If that doesn't get it, try disabling '64-bit Double Precision Engine' and 'Use Multiprocessing Engine' one at a time to see if there's an issue with either of those in your system, or maybe with the related 'Plugin Load Balancing' if you have that enabled.

There is no simple, built-in function for doing this, but it can be done. I've posted this workaround a few times over the years. Awkward, I know, but it works. It would be a lot easier if Cakewalk let you enter times in samples - or even minutes and seconds - but it doesn't so you have to do some SMPTE conversions: 1. Enable Auto-stretch (a.k.a. Clip Follows Project in Auto-stretch mode) on all audio clips. 2. Select a MIDI or audio clip that runs the length of the project (or select in the timeline). 3. Go to Process > Fit to Time. 4. Convert the current Thru time to total frames (usually 30 frames/sec). 5. Divide that by the desired tempo change factor (e.g. 1.10 to get a 10% increase, 0.90 for a 10% decease). 6. Round and convert that new value to minutes:seconds:frames. 7. Enter that as the new Thru, and select Modify by Changing: Tempo Map. 8. Click OK. P.S. Since you're clearly a stickler for correct musical terminology (tempi vs. tempos), note that it's 'ritard' with an 'i'. The old forum would not have let you write '*****'... or even 'ritard' IIRC. ;^) P.P.S. Hmmm. ... I guess using derogitory terms is okay for groups, but not individuals.

How tight does it need to be? Your observation that Fit Improv honors the beat value in the meter gave me the idea that it would be possible to align the timeline only at measures by temporarily setting the meter to 1/1. This is often all I need to do for my purposes, and possibly would be adequate in your case - or at least give you a starting poiint for using Set Measure/Beat At Now to dial it in more precisely.

Hmmm... that's interesting. In most contexts, a beat is always quarter (actual tempo values are always 'quarters/minute', for example). That could actually be useful... But to answer your question, I don't think it will be possible to get tempos on dotted quarters with Fit Improv. SM/BAN is the way to go. What's the actual musical situation you're trying to address?

A 'beat' is always a quarter note in Cakewalk, regardless of the meter, and that's 'non-negotiable' with Fit Improv. Set Measure/Beat At Now allows more freedom in specifying where you align the timeline to MIDI, and treats notes that cross tempo changes properly where Fit Improv has a bit of an issue as discussed in a recent thread.

Yes I understood that. I was just pointing out that it's not documented. Ref. Guide says the Select tool will move a group of notes just by clicking and dragging one of them.

Release the click when the selection is complete, and then click again to move. Works as advertised, and is documented in the Ref. Guide, except that it isn't mentioned that you need to hold Shift to move a selection.

Note that I said you have to release Ctrl while continuing to hold the click before you start dragging. This is what makes it awkward. If you don' release Ctrl, you get a copy.