David Baay

See the Visual Effects tab in Advanced System Settings for Windows and set it to "Adjust for best appearance" if it isn't already. I haven't seen this for a while, but in the past there have been issues with the Now Time Cursor display when some options were disabled.

Are you recording a sequence from the SY77? If so, it's probably sending CC7 Volume controllers. You will be able to change the Volume in CbB after you finish recording and delete the CC7 Controllers from the recorded tracks using the Controller Pane in the PRV or the Event List or Edit > Select > By Filter and delete.

That's not how MIDI and instrument tracks work. MIDI tracks output to synths and Synth tracks receive the audio output of the synth, and make it available for mixing. An Instrument track combines the function of a MIDI track and Synth track with the synth residing in the Synth Rack. Another MIDI track can output to the synth in parallel with the MIDI part of a synth track but not through the synth track. The intent of an Instrument track is to provide a single MIDI and synth audio output track to interact with a 'monotimbral' synth or a single channel of a multitimbral synth. Some time ago, CbB introduced the ability to create a separate Instrument track for each output or (stereo pair of outputs) in a multitimbral synth. This would be the preferred way to use Instrument tracks with a multitimbral synth now. I am not advocating that you use any more or fewer synth instances (although it can be more efficient in some cases to run more instances of a synth with fewer channels per instance) just that you use separate Instrument tracks to route MIDI into and audio out of each channel of a multitimbral synth independently. I have to reiterate that there's no clear indication that your current routing is contributing to the problem, but both the setup and the symptoms are unusual so it begs the question whether they might be related. Also, it makes it harder to diagnose when a single synth channel is potentially receiving MIDI from more than one track. EDIT: I should add that the traditional way of working with a multitimbral synth using a single stereo output from the synth and doing the mixing in the synth, which appears to be your intent, would be to host the audio output with a Synth track (i.e. a normal audio track getting input from a synth) not an Instrument track.

i did a quick test, and could not reproduce an issue and there may not be any. I'm just thinking that a non-standard setup like this is not likely to have been thoroughly tested, and there might be unanticipated side effects, especially as it relates to mute/solo functionality. And there is certainly potential for confusion on the part of the user with regard to conflicting settings of MIDI volume/pan widgets or contention of controllers on different tracks driving the same synth channel.

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.