David Baay

@Bill Phillips I realize this is an old thread, but found it interesting because I have long recommended taking a binary approach to isolating a problematic plugin as the page you linked describes. But with CbB, you can launch the project in "Safe mode" by holding Shift as you click it from File > Open, and then choose to enable only half the plugins as you are prompted for each. This can still take some time, but at least you only have to worry about the ones that are actually used in the project.

Seems your keyboard is sending some non-standard character code or maybe some third-party app is modifying it...? I was just using Normalize (to -12dB) yesterday, and checked Transpose just now, and I don't see this issue with either of them. Minus key in the top row enters a "-", and minus key on the Numkey pad decrements the current value by one.

Ctrl+C ?? The question was how to move the clip; so, yes, cut-paste.

Ctrl+X, select the marker in the Markers View, Ctrl+V.

That's been my main use also since I'm not much of a soloist... but neither is BiaB as it turns out. 😜

Good thought, but this thing just doesn't expose audio inputs in CbB no matter what is or isn't associated with it in the way of tracks.

Intantiating a VST instrument as an insert FX in an audio track is supported in CbB for compatibility with legacy projects that used that architecture before the Synth Rack was implemented, but it's not the preferred method now, and can actually lead to issues such as stuck notes among other things. You can insert a synth in the rack without associated tracks being created either by clicking the + button in the synth rack or by Insert > Soft Synth in the main menu and unchecking the options to create tracks. When an Audio track has a synth output assigned as Input, it becomes a Synth track. Or you can insert an 'Instrument' track which is a combined MIDI an Audio track with an associated synth connecting them. An Instrument behaves like an Audio track and shows mostly Audio controls (other than the Input which is a MIDI port/channel). You can access all the 'hidden' controls of an Instrument track via the MIDI and Audio tabs at the bottom of the Track Inspector. Instrument tracks can help simplify your project. You can convert existing separate MIDI and Synth tracks (one of each) into an Instrument track by right-clicking one of the selected tracks and choosing Make Instrument Track. And, finally, note that it's also possible to create one Instrument track per output of a multitimbral synth. You can read up on all of this in the Ref. Guide.

Glad to help.

The Readme says: - VST3 plug-in now declares inputs as "side-chain" (aux) to work around certain lame DAWs But I do not see a sidechain input being exposed in CbB when instantiated as either a Synth or an insert FX though the plugin properties show 'Max used inputs: 2' which would usually indicate the plugin has a sidechain input. Other VST3 instruments I have with sidechain inputs work fine, so it seems to me it's TX16Wx that's 'lame'. 🙊 Old threads I found about this suggest it has only ever worked with Reaper, but they may be outdated and the sidechain works with some 'lame' DAWs, but not good ones like CbB. 😁

No, but I do know that Cakewalk have never excluded/included individual features or functions in the different 'tiers' of SONAR. They have only ever been differentiated them by the amount of bundled content, and I expect that to continue.

Yes, that makes sense. You might want to go into the Registry and remove that virtual ASIO device for good measure. Just delete the FL Studio folder under HKEY_LOCAL_MACHINE\SOFTWARE\ASIO There is no risk associated with doing this; I do it all the time for Realtek and other apps that add these bogus drivers, but if you're concerned, you can export the registry key before making changes.

Utilities > Cakewalk Audio Finder Tool (CWAF) will also show you what files are used by which projects. It will likely show that all the clips in the Audio folder are in fact referenced by the project. Most likely there are tiny slivers of clips left over from deleting with incompete clip selections. Unfortunately those can be hard to find in a complex project. If you know which files should no longer be referenced by name, you can select each track/lane one at time, right-click and choose Associated Audio Files. If you see one of the 'unused' file names in the list, you can start searching that track/lane for it. If you do a partial selection of a track/lane - even an apparently empty region - you can right-click and choose to see Associated Audio Files and it will show if there's something there or more than the one file you expect. Since it's possible (though unintended) for clips to be layered on top of eachother in the same lane, you'll need to check regions with visible clips as well. Once you narrow down the area, you can zoom in and scroll around to find the troublemaker(s). If the problem involves layered clips, you might have to move 'known' clips to another lane temporarily to find hidden ones. I realize this is a pretty ugly solution, but it's the only way I can think of to track them down.

As noted, it's showing only a 240-sample RTL for a 256-sample buffer. That's just not possible. With no hardware latency, the I/O buffers alone will give you 512 samples round-trip latency. It's typical for hardware/firmware/drivers to add 200-400 samples to this. Your own video shows a reported RTL of 742 samples with a 256-sample buffer. That's likely missing the ADA converter latencies which will typically add another half to a full millisecond each way although some manufacturers are better about reporting everything to the DAW. I'm not sure why the RTL in the screenshot was initially so far off the mark. The 829-sample Reported figure mentioned later by the OP sounds more like it.

Yes, and that's more on the order of what I would expect for a 256-sample buffer on a USB interface. The Total Round Trip of 240 samples in your screenshot made no sense.

TTS-1 is a full 16-channel Multitimbral GM instrument. Like all GM instruments drums are on channel 10 by default. All other channels default to piano, but can be changed.

Sorry. Glanced to quickly; thought you were on the Audio Driver page. MME is correct for most MIDI interfaces. As mentioned, Manual Offset is on the Audio > Sync and Caching page. Easiest way to set it accurately is to download and run the free CEntrance Latency Tester with an audio cable patched between an input and an output on your interface. Then set Manual Offset as the Measured Latency minus Reported Total Round Trip. https://centrance.com/driverfolder/CE_LTU_37.zip

How did you go about that, exactly? So far as I know, SI Drums offers only a basic kit with no percussion or other sounds. It's not a General MIDI instrument. EDIT: TTS-1 offers a full GM drum kit, and there are many free drum synths available that will include at least some percussion.

That shows your Driver Mode is MME, an outdated protocol for PC audio. The Arturia should have native ASIO drivers. Change the mode to ASIO and see what you get. It should work much better overall and allow you to run a lower buffer size. Also, I would suggest you lower your MIDI Prepare Using buffer to 50ms. 500ms was the old default before the MIDI buffering code was revised. Values that high should not be necessary any more, and might actually cause issues.

Had you previously created a Melodyne Region in this particular project as it is currently configured in an earlier version of CbB without issue? If not, and it's not happening in other projects, there's no reason to believe the issue is new to this release. If it's somehow both project-specific and release-specific, the Bakers will have no hope of diagnosing it unless you submit a a copy of the project to Support.

Seems most likely an issue with the Korg as the the interface and CbB would not be aware in any way that a knob s being turned on the synth. Possibly the Korg is generating controller messages that are being received by the track and echoed back out to the Korg. Make sure the Input Echo button is disengaged (you might need to disable Always Echo Current MIDI Track in CbB Preferences) or configure the Korg not to send controller messages from its panel. Incidentally, I don't think it has any bearing on the current issue, but one oddity I see is that that your ASIO buffer is set to 256 samples (applicable each way, in and out), but the reported I/O latencies are much lower than that. This reported value comes from the driver and can never be smaller than the buffer size. That misreporting shouldn't matter in real time, but your record compensation is going to be way off without an appropriate Manual Offset entered in Sync and Caching.

I still think that's only if the selection is partial, and your have Slide over to Make Room set in Drag and Dorp options. And a selection always moves as a contiguous block; clips within the selection should never move relative to eachother. I don't disagree with that, but it should have worked as expected based on my experience. And I'd be really curious to see and understand the scenario in which it doesn't.

If you're using a synth that generates MIDI or echos input to a virtual MIDI OUT, you'll need to ensure that track inputs are set specifically to the port and channel your controller is on rather than All inputs/Omni. This is a best practice in any case.

I'm actually not sure what scenario Mark is describing. I use slide a lot, and have never seen that behavior when sliding an entire track or project, and can't reproduce it now. The only time I've seen anything like that is when moving/sliding a partial selection with Slide Over Old to Make Room set in Drag and Drop options which has always been buggy (later material sometimes moves later than necessary or actually moves earlier when you're moving something ahead of it later). But that's all moot if you're starting with Select All.

Those are all good points/suggestions, but if the OP started with Select All and the meter is contant, that should have worked as expected, at least with regard to clip start times. Would probably need to see the specific project first hand to understand if the result was due to user error, faulty expectations for the circumstances, or an actual bug.

Yes. In both cases, when the buttons are not lit/engaged, the underlying functions (PDC and FX processing) are working. When the buttons are lit/engaged, the normally working-by-default processes are bypassed/overridden.