David Baay

Clips with ARA FX applied can't be split. You must first render the FX by bouncing to clip or make you splits before applying the FX. I believe this is an ARA limitation, but have not tried it in another DAW.

Yes, but you need to be on the latest release and the activation server it uses will eventually be shut down after an unknown - but likely pretty generous - period, so it will quit working when your activation expires. The price of the paid replacement, Sonar (no longer all caps), has been promised to be "very reasonable" (or similar language). If you like CbB, have used it for a long time, and music is important to you, you should just plan on shelling out when the time comes. All the discussion about this reminds me of the answer that's commonly given on motorcycle forums when someone asks how much they should spend on a helmet... "How much is your head worth?"

The right tool to use and how to use it depends on whether you want values between 110 and 127 to be raised proportionally. One key thing that's often overlooked about using Find/Change is that it needs an initial selection on which to operate, so you need to start by selecting the clip or part of it either in the track view or the PRV. To just bring the velocities below 110 up to 110, Enter Min and Max of 0 and 110 in the Find dialog, and 110 for both Min and Max in the Change dialog. To compress everything upward proportionally, you need to know what the lowest velocity is; if it's not known and not easily found, LoVel.CAL can find it for you. Then enter that as the Min in the Find dialog with 127 Max, and enter Min/Max of 110/127 in the Change dialog.

Bounce to Track(s).

Yes, I see that. If you want to snap to clip landmarks, the Landmarks button needs to be activated.

Did you get mobo/chipset drivers installed?

Clearly it's got issues. Have you tried running any other apps on it? How custom is it? Have you done general checks of system health?

Plugins either require delay compensation or they don't; a powerful CPU will make no difference in this case. And when plugin load gets too high for a given CPU and buffer size. the result is not increased latency, it's Rice Crispies. Plugin Delay Compensation can be temporarily overridden while recording Input-monitored tracks (including Synth/Instrument tracks) by the PDC [override] button in the Mix module, but only if the PDC-inducing plugin isn't in the path of that track to the output.

Define "can't use". What are the exact symptoms? What type of drive is D:, and what else is on it?

Mute the clips and enable Hide Muted Clips in the PRV.

In the past, just the presence of Steinberg's Generic Low Latency Driver on the system has been reported to cause problems with SONAR/CbB, and it's usually been recommended to remove it.

As mentioned in your other thread, CbB uses the ASIO buffer as the default "chunk" size for offline rendering and some plugins can be sensitive to it - more often when it's too small than too large. But in general, offline rendering will work just fine even when the buffer is too small to get pop-free plyback in real time. The reason is that there's time pressure to keep the interface driver supplied with a steady stream of buffers when rendering offline. If a particular buffer takes a little longer to process for whatever reason or a some other system demand interrupts it, the CPU can take a l long as it needs to process it and write it to file.

Clips with ARA FX applied can't be split. You'll either need to remove the FX or bounce it into the clip.

Both my DAWs are always online, and I've not seen any issues. And CbB does not "phone home" every time you launch it. Activation files are stored locally and don't get refreshed until they expire (several months at least) or an update is installed. Different users are reporting "slowness" at different points: launching CbB to the Start Screen, scanning plugins, "Loading tracks and clips", "Creating UI", "Almost done", etc. Several of these "slow load" issues have been resolved by specific actions like eliminating a big archive file that's being picked up by the Media Browser (not a new issue), adding exclusions to A/V scanning, removing or reverting to a previous version of a plugin, power-cycling the interface, rebooting, etc. In addition to the tendency of users to attribute every new issue to the most recent update, there's also a tendency for user's to see a very generic problem description like "slow loading" and latch onto that as matching their issue when there's actually no commonality to the exact symptoms or root cause.

Not really, because more and more instantaneous amplitude information is being thrown away as fewer bits are used to represent it at lower and lower levels. Applying gain to a low level signal just gives you a louder representation of a poorly detailed signal. This might not be too egregious for the first 24-30dB of attenuation, but the lower you go, the noisier it will get.

Ouch. I might have to re-read that few times, but it seems to me it would ultimately be simpler to have a separate track per patch with forced output channels and leave both your keyboard and your expression controller on channel 1. When editing in the PRV you can show all the tracks together, and it might even be helpful that the different patches have different track colors. But if you use the staff view, separate tracks would obviously not be ideal. And it's going to drive up the total number of tracks in a template that's probably pretty huge already. I'm thinking a workable variation of your current setup would be to have one "Master MIDI IN" track with its Input set to Omni on which you set whichever forced output channel is needed at the moment. And that track outputs to a plugin that echos the MIDI for all the individual instrument tracks to receive with their respective Input channel restrictions. Possibly your existing "midiChs" could be that plugin but I like using CodeFN42's free MIDIChFilter for this purpose. Some plugins of this type introduce a slight MIDI delay, but MIDIChFilter does not. In this case, it wouldn't be changing the channel, just acting as one-to many MIDI "patch point" for the instrument tracks.

I ran into a similar problem several years ago (2018 per e-mail I sent to the Bakers at the time), but with the Basic template itself. CbB default for new projects was set to 48kHz, but my interface would respond to something in the template and switch to 44.1kHz after a few seconds when starting a new project from it. In playing around with it, I somehow ended up creating a copy of the Basic template that did the opposite, switching the interface back to 48kHz when the first project had switched it to 44.1. I submitted both templates to the Bakers, but they couldn't reproduce it and confirmed templates shouldn't do this. They could only suggest that something was going on between Windows and the MOTU driver, but I never did get to the bottom of it. I only ever used the Basic template to create "clean" bug demo projects for the Bakers so I've just continued using the "Basic (48kHz)" version to do that. And I've never had any issues once audio was recorded a project; CbB would always match whatever rate was set in the audio files. So I just checked, and the issue no longer occurs with that original Basic template file in the current CbB, using all the same hardware and Win10 installation I was running at the time. I have CbB referencing custom file paths for Cakewalk content so updates don't overwrite anything, but that template file's Last Modified date is the same as the currently shipping one written to the "Cakewalk Core" directory: 8/21/2017. All that said, what interface are you using, and are you sure it's responding to CbB's request to change rates? Some interfaces like my Roland Duo-Capture have to be physically switched. If you open one of the audio files in another audio application or just look at the file properties does the bit rate agree with it being 44.1kHz? (706, 1058 or 1411 kbps per channel for 16-bit, 24-bit or 32-bit files)

Is there a tutorial or set of instructions somewhere that shows how to channelize MIDI notes using articulations? You can see in the Transform Existing MIDI Events section of the screenshot from the Ref. Guide that you can change the channel of existing MIDI events. I guess this is what the OP was referring to. Assigning a forced output Channel to the track should eliminate the need to do this transformation, and will operate on live input as well as existing MIDI. https://legacy.cakewalk.com/Documentation?product=Cakewalk&language=4&help=EditingMIDI.54.html

Nice. Looks like a potentially rich source of buggy behavior that can be blamed on CbB. ?

I'm not completely understanding what you're saying here. When you have multiple MIDI tracks driving a muti-timbral synth, you set a forced output Channel of each MIDI/Instrument track to match the channel associated with each instrument/patch in Kontakt, and that channel assignment will dynamically re-write all MIDI to that channel whether it's live input being echoed/recorded from your controller or playback of existing MIDI. There is no need to change transmit channel on your controller; it can always be channel 1, and all your track Input port/channel assignments can be channel 1 of the port your controller is on. Whether you're playing back keyswitches in existing MIDI or sending them from your controller in real time, those will also be re-channelized to affect the appropriate instrument/patch in Kontakt. If you're playing/rehearsing without the the transport running, whatever articulation/keyswitch was last sent to the Kontakt instrument will persist until a new one is sent, either from your controller or by starting playback of an existing track with articulations on it.

Does it reproduce if you delete everything but that track from a copy of the project? If so, you should save that stripped down project to a new location, zip it up and send it to the Bakers.

The plugin is already disabled by freezing the track. My guess would be there's something else going on in the project coincidentally at the same point that's causing the problem. Try archiving the track to check that. In the past, I have seen these kind of amplitude spikes happening in real time with specific plugins applied to dynamically stretched audio with the 64-bit Double-Precision Engine. My first inclination when seeing any kind of plugin misbehavior is to try disabling 64-bit DPE and see if the problem goes away. And if any of the audio is being stretched, you might want to consider rendering it by Bounce to Clips(s). Also, some "Goldilocks" FX don't play nice when rendering offline at very low or very high buffer sizes. You can set an intermediate value for BounceBufSizeMsec in Preferences > Audio > Configuration File (AUD.INI) to override the realtime ASIO buffer setting that's used by default for offline rendering. I've had mine set to 20 (milliseconds) for years without an issue, but if the plugin is having trouble with a larger buffer size, you might want to try something on the order 10ms (480 samples at 48kHz).

Another option is to split the clip and use Clip FX to apply different treatments within the same track. https://legacy.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Mixing.30.html

I think he might have missed that the order of synths in the rack did not match your tracks initially while his did. I'm guessing you either re-ordered tracks or did a synth replacement earlier on in the project that caused the discrepancy.

Highly likely a misbehaving plugin. What's on the track?