David Baay

Most likely an FX plugin, but based on the symptoms sounds like the 64-bit Double Precision Engine might also be involved so you might start by disabling it in Preferences > Audio > Driver Settings. Is there any recorded audio and/or stretched audio in the project or is it all synths?

Your screenshot appears to show you are using both separate MIDI tracks and Instrument tracks (combined MIDI and Synth audio). I noticed recently that it is possible to direct a second MIDI track to a synth that's set up as an instrument track, and it will work, but this is a bit of a non-standard setup, and potentially problematic. I would suggest using one or the other with any given synth - either separate MIDI and Synth tracks or Instrument tracks. And in either case, synths should be inserted in the Synth Rack rather than in FX bins of Audio tracks.

I only took lessons briefly/intermittently as a child with a couple different teachers. I recall one of them telling me I should curl my fingers like I'm holding an orange. Whether due to that advice (unlikely) or just my natural tendency (or tendonsy?), I do play with curved hands, but I have seen some fairly accomplished pianists play with quite flat hands. Nature or nurture?

I'm sure that reported number is wrong. So you won't hear/feel more than is typical when input monitoring, but CbB will use the reported input latency to compensate the audio position when recording stops, and will end up over-compensating so playback will be early. Also this can potentially cut off the attack of the first note if you start recording from time zero or use punch-in. As much recording as you do, I would think this would have become evident at some point unless you already have your Manual Offset dialed in and just forgot about it. .

Yeah, i understood that. it's just weird. I guess you have a big negative Manual Offset entered in Record Latency Adjustment to get accurate record compensation...? Or possibly you've never noticed it's over-compensating? If not, you'll want to set the Manual Offset = CEntrance Measured - CbB Reported RTL The delta should be consistent at all buffer sizes; if not, that would be further evidence of a driver issue.

I linked the CEntrance utility to my post in case you want to check the actual RTL - you just need to patch an Out to an In to create a loopback path for it to measure.

That's indicating a ridiculous amount of reported hardware latency - almost certainly the driver is misreporting. I'm not sure how it would have bearing on the issue since it shouldn't come into play until recording stops, but I'd be curious to know if other Scarlett users are seeing the same, and what the actual round-trip latency is as measured by a tool like CEntrance ASIO Latency Checker or by checking the position of re-recorded audio with record compensation disabled. EDIT: Seems the original Latency Checker page has been removed, but you can still download the utility via this link: https://centrance.com/driverfolder/CE_LTU_37.zip

The first step would be to determine if it's a MIDI problem or an audio problem. Since you already have separate MIDI and synth tracks, Check the MIDI track meter when the synth is not sounding to confirm MIDI is or is not being echoed (MIDI track meters are output meters, and are not affected by the arming state) If it's a MIDI echo problem, possibly the 'Always Echo Current MIDI Track function is failing somehow, in which case you might try forcing Echo On by clicking the button. If MIDI is being successfully echoed, and the synth is not sounding. I would check to see if disabling Zero Controllers When Playback Stops might have a bearing . Depending on the synth, this might be evident from watching for the mod wheel or faders in the synth's UI to change when the transport is stopped/started. It would be unusual for a channelization issue to depend on the state of playback, recording or arming, so I doubt that's relevant.

Yes, that occurred to me, but I was thinking it could be based on the action of a deleting a connected object, specifically.

I actually reported as a defect a long time ago that automation editing should not create two nodes on the same timestamp. For consistency and ease of editing, it seems to me that an 'instantaneous' change should always be represented as a jump segment.

Maybe there shouldn't be, but based on the video, it seems there can be...? Jumps just seem a lot more logical and simpler to deal with - one node per change. Seems kind of weird to see two different tempos on the same timestamp in the tempo list too.

It's a bit hard to follow exactly what is happening, but the tool shown is for moving the split point not the slip-editing tool for moving a single clip boundary. Moving the split point will replace the waveform on the left side with the waveform on the right. While the behavior you captured does seem a bit buggy, I would say the root of the problem is that you have two tempo nodes on the same time to begin with rather than having a single node with a 'jump' transition from the previous tempo. Moving the single node at a jump point will behave as expected.

At a minimum, you should compare and/or swap AUD.INI files between the two installations. Assuming you're on Windows 10, whatever issue you're experiencing is highly likely to be a config problem. CbB started with the codebase of SONAR Platinum that was as stable or more stable than anything before it and has continued to be developed by many of the same people, including former Cakewalk CTO, Noel Borthwick, Given that, there would be no reason for "teething problems". Clearly your experience and the OP's are exceptions to the rule that that vast majority of users who didn't bail while CW/SONAR was temporarily orphaned have happily moved on to CbB and would never consider going back to any release of SONAR and losing the hundreds of new features and assorted improvements that have been implemented since. I took advantage of the Studio One crossgrade deal that was offered when Gibson abandoned Cakewalk, just in case the abandonment turned out to be permanent, but have never found a good reason to continuing using it. Bottom line: You should make every effort to figure out why CbB isn't working as well as X3 on your system. You have nothing to lose but a little time and everything to gain.

@Noel Borthwick Maybe a prompt is needed when removing the last send/receive end of a patchpoint, asking the user if the patchpoint should be removed, similar to removal of a synth prompting to remove related tracks. I recently discovered I had a "send to nowhere" from the Metronome bus because I had deleted the click track it was feeding and forgot about the patchpoint.

Good deal. I should have made it clear where the PRV-specific To/By setting is; it's a bit hidden. Cakewalk is so deep it's really easy to overlook things like this, but I try to trust the software and question myself first when something unexpected happens.

I do it regularly; a lot of my compositions lately are using it - sometimes including the second above the low note in which case I'm hitting both with my thumb which shortens the distance. But I can do the 9th by itself pretty easily with the same span.

Actually, no. I use it all the time and have not seen unexpected behavior for a long time except when settings were not right for what I wanted to do - i.e. user error. There were some issues within the first couple years of its introduction (back when major releases were only annual) but so far as I know everything has been ironed out at this point. I'd be really interested to see a copy of a project that isn't working as expected.

7.75" and can't reach more the an octave plus a second, either, but I've had no complaints.

I just picked up one of these to replace my ancient MIDI Express XT. My main goal was to reduce MIDI transmission delay, and the mio XL delivered in spades. The MOTU was one of the first Windows-compatible versions delivered, and was quite slow - about 5ms each way. The mioXL is barely over 1ms each way - gotta love it. Unfortunately I don't have much to offer the OP in the way of suggestions other than to leave everything connected as bdickens suggested and make sure it's all turned on before starting Cakewalk. And whatever you do, don't re-save a project that isn't routing correctly. That said, even when I would forget to turn on the MOTU, Cakewalk was picking it up just fine when it was turned on with a project already open running, and I've never had soft synth ports get mixed up when hardware ports were missing. But I don't have any control surfaces set up at the moment which may be a factor. And I don't run other USB MIDI devices either; everything went through the MOTU and will now go through the mioXL.

Snap 'By' instead of 'To' enabled for PRV snap? Or the Snap to MIDI Events button is enabled?

I recall running into this quite a while back. I believe I submitted a project to the Bakers but don't recall whether anything ever came of it. I'll have to look back and see if I have notes or a demo project.

Given that you just want to be able to pass a contiguous range of notes in the center and save it as a preset filter that can be applied to multiple files, I second musekamp's approach. The drum map solution was needed in my case because the passed notes weren't a contiguous range, and I didn't plan to delete anything. I just wanted be able to hear what was missing, and then transpose/re-orchestrate to preserve as much of a performance as possible.

It only seems global because the Cakewalk forum is a hotspot.

It might be, but there must be more to it than that Set Project is generally broken. Must be something project/content/configuration-specific. EDIT: Can you share the audio file?

Yeah , I thought the "4:17" sounded familiar. Here's Noel's response to the original thread: