David Baay

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.

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?

The tagline from the old (maybe before your time) margarine commercial comes to mind: "It's not nice to fool Mother Nature". I can repro that CbB remembers the original order of the virtual ports in the rack and continues to render in that order. Apparently the render order is stored separately, and not re-ordered by the sneaky rack re-ordering trick. I'm still not clear what the ultimate goal is but it might be time to just tell the little OCD man in your head to go away and find something more important to worry about. I have to do this pretty regularly myself.

When simply recording multiple takes sequentially each clip will get its own dedicated file, except in the case of loop-recording where the clips in multiple lanes will all reference a single file because it's really just one "take". When you comp, the comp will indeed be based on pointers to the different files. Not sure what you're getting at, though...?

@msmcleod As mentioned ealrier in the thread, I found that Duplicate Track properly applies the result of automatic slip-editing by Punch Recording with Mute Previous Takes enabled to give the desired result. It seems to me it should be possible to do this transparently within the track. Melodyne already honors manual slip-editing; it's just not getting the message that the clip boundaries have been changed when it's by punch-in.

All of the non-destructive gain-staging methods available in CbB are going to process with the same precision in real time - 32 bits or 64 if you have the 64-bit Double Precision Engine enabled (which it is by default). It doesn't matter where you do it in the virtual chain. Nothing happens to quality until you bounce/export to file at a lower bit depth and/or sample rate, EDIT: I should mention, however, that plugins that affect dynamics will of course behave differently if the change is a pre-FX gain change vs. a post-FX volume change.

Unused files can also be cleaned up by Utilities > Clean Audio Folder which operates only on the currently open project or by Utilities > Cakewalk Audio Finder (CWAF) which can scan all projects, show you what's used where, what's missing and and what's not used anywhere ("orphaned"), and let you remove all orphaned audio in one go. But it takes a little setup and understanding to use it properly. I've posted a usage tips a few time over the years; here's one: https://discuss.cakewalk.com/index.php?/topic/50614-files-have-become-disassociated/&do=findComment&comment=386320

Will need to look at the project file that warns of missing files. You can delete all the MIDI content from a copy if you don't want to share it.

One of the autosave versions may be referencing those files. If yoyu run Clean Audio Folder from the Utilities menu, it will identify any files that are not referenced by any project. If nothing shows up, on of those backups is referencing them. But that's different from projects with missing files reported. Can you share one of those?

Great summary and explanation. But based on my testing, and the effectiveness of using Duplicate Track to get the desired result, I think it's within the Bakers' ability to address this without enhancing either Melodyne or ARA. As the OP suggested early on, CbB just needs to 'refresh' what's being presented to Melodyne after applying slip-edits due to punching in. Duplicate Track does that so the Baker's should be able to make it happen transparently within the existing track.