brundlefly

Yes, every software instrument has a dedicated port so there's no need to differentiate channels unless the instrument is multitimbral and you actually want to use it that way. Even then, the events can still all be entered/recorded with the same channel, and you can use the forced output channel assignment on the track to re-channel them.

Hold Ctrl+Shift when changing the first port/channel and they will all change. Or Change one and hold Ctrl+Shift when changing another one to have that range changed.

I'm no expert on plugin technology, but my basic understanding is this: Every plugin has a Unique ID assigned (by registration with Steinberg, I believe). If it changes for any reason, the DAW will not recognize it as being same plugin. This is not a Cakewalk-specific issue. The UID will typically change if the new plugin is VST3 where the old one was VST2 or 64-bit vs. 32-bit, but may also change when the manufacturer adds capabilities to the new version and re-registers it as a new plugin because existing presets or parameter mappings are not compatible with the original implementation. The only real solution is to ensure you re-install the legacy versions of the plugins for compatibility with old projects. Since they have different UIDs, they should be able to coexist with the newer versions both in the O/S and in projects, but it's probably best to install them in chronological order if possible.

Those look like display artifacts to me. I sometimes see this, but only when zoomed far out (e.g. showing the full song length) on clips with fairly dense controller data. In my case, that's usually continuous sustain controllers on piano tracks where the controllers display as triangles at the bottom of the clip so would not be generating vertical lines in any case. There may be an interaction with specific displays or graphics controllers that makes it happen at different zoom levels on different machines. I've never looked into it that deeply as it's not an issue at the zoom levels I'm more typically working at with a minute or less of the timeline showing.

There is no such thing as a "clip file". An audio clip is a virtual object defined in the program that references an audio file on disk. Everything about that clip other than the raw sample content and some basic metadata that are part of the .WAV file definition is stored in the project file as an object property - name, start time, length, clip automation, fades, transient markers, etc. Two completely different projects can reference the same audio file in the same location on disk and have it start at different times in the project and have different non-destructive edits applied to it. In fact, this is exactly what happens when you save new versions of the same project in the same project folder with evolving edits over time. Nothing is written to audio files until you bounce and then a new file is written rather than overwriting the original.

Which would of course be the usual use case. Glad you got it figured. I just came here t post a link to the bug demo project I sent to the Bakers last year, but i guess it's not necessary now. Oh, wait, I guess it is. Here's a link to a project that shows the issue without sidechaining. See the Notes for a complete description. There were some other issues that are no longer reproducible in 22.02, but the delay compensation issue persists. https://1drv.ms/u/s!AvHuw7srYo1slQ4ZYAPxRQOH5Sea EDIT: I just brought this file into my laptop to verify the download and realized this .zip file has an old version of the bug demo project that does not have notes. Suffice it to say that if you zoom in, you will see that the clip in Track 1 had to be slid 140 samples late to make it null with the copy on Track 2 that is going through the upsampled Channel Tools. Note, also, that per-plugin upsampling enables are stored in the registry, not with the project, so Upsample on Playback/Render for Channel Tools has to be enabled on your system.

Yes, I think that's why it's not a good test of the Upsampling issue. With Upsampling alone, some delay is introduced but PDC is not invoked. Your test suggests that having some plugin in the project that's reporting delay to CbB causes PDC to be invoked, masking the problem with Upsampling, especially in the case that the plugin introduces more than 140 samples of delay which I suspect Transient Shaper does since the added latency is noticeable. I'll give it a try when I have some time.

Transient Shaper itself induces PDC so not the best choice. When this was first reported by the OP last year, I verified it using Channel Tools and the issue still reproduces for me in 22.02. I had to nudge the non-effected track 140 samples later to get them to null. I reported it to the Bakers but did not get any confirmation back.

In case you're not into watching videos to get quick answers, the root of the problem is likely that the Input selection in your soundcard/interface's mixer app is set to record from the output. This is not usually an issue with external audio interfaces, but is common with onboard soundcards.. Creative called this input setting 'What U Hear'. Realtek generally calls it 'Stereo Mix'. You need to change the Input selection in the mixer app to something like 'Mic/Line'.

Possibly tempo-related? As a test you might try changing a copy of one of the problematic projects to have the same tempo as a working project and see if the issue is eliminated.

This is not meant insultingly at all, but that's what the Ref. Guide is for. It's quite clear about how swing works. Normally you should not have to type anything; Quantize will default to 50% the first time you use it in project. Swing Many projects do not have notes positioned on a perfectly even time grid. For example, projects with a swing feel, though they may be written entirely in eighth notes, are often played more like eighth-note triplets, with the first note extended and the second one shortened. The Swing option lets you distort the timing grid so each pair of notes is spaced unevenly, giving the quantized material a swing feel. A swing value of 50 percent (the default) means that the grid points are spaced evenly. A value of 66 percent means that the time between the first and second grid points is twice as long as the time between the second and third points. The following figure illustrates the effect of the swing setting on the timing grid:

I have no problem saying the origin of that 'glitch' is a likely a bug, ;^)

Splitting does create slip-edited (a.k.a. 'cropped') clips, but all clips are virtual representations of the underlying audio file whether they've been slip-edited or not and it should not be necessary to bounce a slip-edited clip to do anything you would do a with a 'normal' clip.

Cool. I thought it might just be glitch due to the high volume of downloads during the GB. I did the Syner-V installation shortly after the problem was mentioned and just the first part was missed. Downloading and installing manually fixed it.

I know there are a lot of posts about soft synth port assignments changing when hardware ports go missing (arguably user error) or, similarly, when soft synths change the number of ports they present to the host (not ideal). But that problem will resolve itself when the missing ports are restored so long as you don't save the project in the bad state. Other than that, I am not aware of any confirmed issues with CbB's handling of MIDI ports that aren't 'just how it works', like inputs getting assigned to Omni when you have Always Echo enabled and don't deliberately assign a specific port and channel. But, enough hijacking of this thread. If you have a recipe that's even somewhat repeatable - and not synth-specific - you should post it to the Feedback forum.

Yes, I was making that mistake - cleared up a few posts later.

Maybe not user error, but not universally experienced, either, so won't get fixed until you can find a recipe and share it with the Bakers. Not likely the OPs' issue in any case.

I have seen that happen previously with a Syntronik 1 synth. I ended up just manually copying the missing folders from the extracted installation files to the samples directory. Worked fine. EDIT: on re-reading I see the issue is not just that the files weren't installed, but that they weren't even downloaded. In that case you can download the missing parts from the IK website, extract them, and run the installer.

8 Freebies!

I'm not sure what that's referring to...? I was suggesting a possible misconfiguration by the user not some inherent problem with CbB.

Set a loop to start at the first marker and encompass the whole piece, then W will take you to the first marker. I use this whenever I want to repeatedly return to the same non-zero starting point. Hitting W repeatedly will alternate between 1:01 and the start of the loop.

I have always presumed they do this so that bass parts are playable on smaller controller keyboards without transposing. But, yes, you would expect a given vendor's products/patches to be consistent.

Do track and bus meters show signal from the start? Almost certainly an interface/driver issue. What is it? Possibly failing pre-amp section if you've had it for a long time. Try the headphone out if it's an external interface.

Was going to suggest ye golden olde problem: Punch region is set further out in the timeline. But if audio recording is working in the same region where MIDI recording is failing, that would not be it. Cannot think of any other config issue that would have MIDI being echoed but not recorded unless possibly another track is doing the echoing and the armed track has the wrong Input port/channel assignment...?

Indeed. I was mistakenly thinking the limit was 1/3 rather than 30%. Tune in next week for another episode of Stoopid User Tricks. ;^)