David Baay

For anyone that doesn't have everything Waves, and just wants a few pieces: - Get another 10% off with code YNY23. - You can buy 2 and get 2 free with each order so don't buy more than 2 at a time. - Note the fine print: "Free plugin selection must be completed within 72 hours from the time of purchase."

Best wishes, Gary. Sweet photo.

Can't help you, but wanted to share my favorite handpan video:

My guess is it would take additional code to deliberately exclude the FX bin from obeying the '1-second rule', and this simply wasn't considered. It's only noticeable because the FX bin is the first object your cursor encounters when passing out of the clips pane into the tracks pane and it's big.

I think you are mis-remembering in this particular case; Slide Over to Make room has not worked correctly for well over a decade if it ever did; down-stream clips that didn't need to move would move and would move to the right even when you were dragging something to the left. Ripple Edit addressed this and many other case where Add Measures, Delete Hole and related actions would not deliver expected results. For the most part, the old ways still work (or still don't work) as they used to when Ripple Edit is disabled.

What are the exact symptoms of "don't work"? In the absence of an actual bug, a change in behavior after close/re-open would usually be due to having incorrect focus, selection, tool or some other program 'state' that is not compatible with what you're trying to do and is not saved as part of the project. Pretty hard to diagnose without having the project in front of you or steps to reproduce it. All I can say is that these unexpected things do happen to me, but I can pretty much always find the cause and correct it without having to shut down.

I can reproduce that, but only while the cursor is over an FX bin after leaving the clips pane - hovering over any other part of the tracks pane works as expected, and once I've scrolled in the tracks pane, it works when over an FX bin as well. And I can confirm Platinum did not have this quirk. Had not noticed it until I went looking for it. I guess I just don't normally stop over the FX bin when scrolling in the tracks pane. P.S. I'm on Windows 10.

I finally broke down and got another 10% off with code NERDS10.

Indeed, it would be good to download the Ref. Guide and do some reading. - The Event List shows controllers in red to distinguish them from notes. - You can select in the Event list by sweeping the mouse down the far left column of the view, and delete the selection by Edit > Delete (Delete key will only take the currently focused one). - Select by Filter works by filtering the current selection so you should start by selecting the whole clip in the track view in this case. EDIT: By the way, base don that Event List, it looks like a volume fader/knob on your SY777 might be 'jittering' and sending superfluous controllers almost constantly which is going to cause various problems. You might want to look into disabling it or routing it to an unused channel if possible. Or try exercising it to clean it up and/or find a position where it doesn't jitter.

Cakewalk doesn't render the metronome when exporting or bouncing, even in real time. You need to arm that aux track and record the click first. Then you can include the click track in an export

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.

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.