David Baay

Hmmm... yeah. that may help in some cases. I leave it disabled because it has other side-effects I don't like, and some actual bugs, so I kind of forgot about it. It's been so long since I thought about it, I'd have to go hunt up some threads on the old forum to remember all the issues. With all the work the Bakers have done in the last few years, some may have been fixed in the mean time.

Actually, this has always been a thing. Cakewalk came late to the concept of MIDI 'clips, and their boundaries have always been defined by the starting and ending event times. The exception is a MIDI Groove clip which has a defined number of Beats in Clip that allows it to have empty space at the end. So one way of dealing with this is to convert the clip to a Groove Clip. Their are ways of preserving empty space in a MIDI clip when doing certain operations, but the only surefire way is to preserve space no matter what you do is to insert dummy controller events ( I usually recommend Pedal Up, CC64=0) or silent, zero-velocity note events in the clip at the desired start and end times.

Muting clips and enabling 'hide muted clips' is only necessary when you want to hide notes in different lanes of the same track. To show only the notes of one track, you just need to open the Track Pane at the right side of the PRV (View Show/Hide Track Pane. This gives multiple options for filtering what you can see and edit. Normally it will default to just showing the track you double-clicked as you expect: http://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=EditingMIDI.10.html

Looks like a bug. Try enabling Ripple Edit All.

I have not actually tested this, but my expectation would be that drag-to-timeline should give the same result whether the clip timebase is changed to Absolute or not, even if clips don't all start at time zero. Drag-to-timeline treats clip start times as absolute whether you set them that way or not. Like Set Measure/Beat At Now, it uses tempo changes to shift the timeline against the absolute playback timing of both MIDI and audio without affecting either (MIDI event times and durations get re-calculated to preserve the absolute timing).

Tempo Offset will do it proportionally (i.e. by percentage): http://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=Tempo.11.html

If it doesn't happen with a different instrument playing the same MIDI part, I would strongly suspect the problem is internal to EastWest. Your mentioning it uses a round-robin system for sample variety makes me wonder of some samples are bad/missing. You might test this hypothesis by adding the same note earlier in the sequence, and seeing if the drop occurs at that earlier instance, or just changing the pitch/articulation/velocity of the note that's getting dropped. Another technique I have sometimes used to figure out whether a rendering problem is in Cakewalk's buffering process or in the VSTi itself is to loop the MIDI output from a physical OUT back to an IN, using another track to echo it to the synth, and see if the problem manifests when the synth is responding to 'live' MIDI input as opposed to being rendered from existing MIDI. If the live-input scenario works as expected, I'd be more inclined to suspect the issue is in Cakewalk's buffering/rendering machinery, and take it to the Bakers. I have also seen cases where a slight change in tempo eliminates a dropped note. This would also tend to indicate the problem is with Cakewalk.

Regarding legato.cal. It's working (or not working in this case) as it always has; it only works as expected with monophonic melody lines. As-written , it is not capable of handling chords. All it does is go through the event list, sequentially, and set the end of each note to match the beginning of the next (with or without a specified gap). In the case of chords where the start of the 'next' note in the 'sequence' is the same as (or close to) the current one, you naturally end up with a note that has little or no duration. It might seem like a simple thing , but it would take a lot of additional logic to recognize and handle chords properly, and this is challenging in CAL because of the way it processes MIDI events in strict order of start times. EDIT: I realize I'm way late to the party, and some of this may have been covered already, but while I'm at it... Regarding copy vs. cut behavior, I think it's debatable whether this is a 'bug', per se, but consistency in behavior when including space in the selection would certainly be helpful. Regarding Audiosnap, it certainly has its share of issues, but in this specific case the problem is self-inflicted by having the Follow Option set to 'Measures' instead of 'Autostretch'. The 'Measures' option make Audiosnap immediately try to 'fit' the clip to the project at measures based on the clip tempo map. If you just want the whole clip to stretch proportionally as changes are made to the tempo, you need to choose the 'Autostretch' option before enabling Follow Project. I understand the OP's wish to have Cakewalk be as solid as possible, but 'bugs' are often addressable by changing one's workflow slightly or just having a better understanding of how things actually work vs. how one might expect or prefer them to work. As such, it's not usually helpful to immediately ascribe 'buginess' to a something that doesn't work as expected before running it by the forum as a simple question: Is this expected, or am I doing it wrong, or is there a better way or a setting I can change to make it work the way I want?

If there's an issue, it would have to be very new. What exactly are you seeing/hearing? Basically you're saying that if you open a MIDI file as a new project, and then import that same file into a new track(s) in the same project that corresponding events won't have the same velocities. Is that right? Can you share an example file?

This was fixed in CbB. The workaround was to Alt+Tab to another application, and then back to Cakewalk.

Historically, the fix for dropped MIDI notes was to increase the value of the MIDI "Prepare Using" Buffer. Long ago, the default was 500ms; when SONAR X1 was released the default was reduced to 250ms which caused dropped notes in some projects just as you describe. In the 2019.11 release the following bug was reported fixed: - Setting the MIDI "prepare using" to 256 ms or lower causes missed or stuck notes. Along with that bug fix, the default was reduced to 20ms with the following notes: - The Default MIDI Prepare Buffer size has been reduced to 20 msec. Limitations preventing the MIDI buffer from being set lower have been removed. There should be no need to change the buffer size from the new default value anymore, since the engine automatically raises the internal size when necessary. - On first launch, Cakewalk will reset the MIDI buffer size to the new default value of 20 msec (Preferences > MIDI - Playback and Recording > Prepare Using n Millisecond Buffers). Notwithstanding the note about the engine automatically raising the internal size when necessary, there may still be situations where it's necessary to set the starting point higher, such as when using FX that use look-ahead buffers that trigger a lot of Plugin Delay Compensation. Some synths may also be more sensitive to it. I suggest trying a value of 50 or 100 or more, and see if it helps.

I'm also curious about the need for a 7/8 groove-clip in a 4/4 project. In any case, I would just blow off the groove-clip feature entirely, make a regular MIDI clip that's 7/8 long, and copy-paste as needed with snap at an 8th or with landmarks enabled to snap to clip boundaries.

Just to be clear, when you say "MIDI track", are you really using separate MIDI and Audio tracks for input to and output from MTPower, or is it a Simple Instrument track that combines MIDI and Audio features in one track? If the dipping/ducking is really related to the guitar signal it sure sounds like you have a side-chaining compressor on the drum track taking input from a send on the guitar track, but that wouldn't happen by accident, and would be hard to forget unless this is a project you're coming back to after a long time or was created by someone else....? But it would explain the behavior since a prefader send wouldn't be affected by muting the track unless you deliberately altered the default behavior by setting LinkPFSendmute=1 in the Config file (AUD.INI). If that's not it, you should share a copy of the project somewhere so we can figure out if the issue is in the project or in your DAW setup.

You may need to enter a more negative dB value for Other Beats in metronome properties. I usually go with -1 and -7dB for First Beat and Other Beats, respectively. I think the default is only 3dB lower, and does not provide enough 'contrast' for my taste.

No, but it does rule out that it's independent of the environment in which it's running, and the project content (i.e. Spitfire synths). Hmmm... that's quite different from "The worst thing about this is that even after rolling back, I'm still having issues with drop outs on Spitfire's OPW... now all of a sudden it's killing my projects. and "I'm getting serious choking even after rolling back." If rollback did in fact resolve the issues, and they are all related to Spitfire then you should report that in the 21.04 Feedback thread. I reported an issue with Izotope Iris 2 during EA that turned out to be related to the large number of automatable parameters it exposes interacting badly with the new automation code. But that was fixed, and was only noticable on my system at very low buffer settings of 32 samples. Even then, it wasn't causing 'serious choking', just crackles and pops showing up sooner than expected. In any case, it sounds like something about Spitfire synths, specifically, is also causing an issue with that new code in which case the Bakers will need to look into it. It will help if you report the symptoms and conditions in detail.

I long ago lost count of the number of reports of issues caused by updates that were eventually traced to some other root cause. Rollback pretty much eliminates the updated code as a cause of the issue. I suppose it's possible some other system issue was precipitated by the download or installation process, but you should still check DPC Latency whether you believe anything else has changed or not. Also, have you checked that interface driver mode and buffer size are unchanged...?

Check your system DPC Latency: https://www.resplendence.com/latencymon New hardware/firmware/driver updates can drive DPC latency up. Low is good - preferably no more that 200-300us (microseconds) - but stable without spikes is even more important. Bluetooth and WiFi drivers are common offenders, especially BT. They can be disabled in BIOS if/when not needed.

Pan one hard left, one hard right, and bounce to a new track with Channel Format set to stereo in the bounce dialog. Depending on your pan law setting in Preferences, the levels may change slightly.

Switch to the Edit tool. Smart tool wants to move the split point by default, but Edit tool will default to slipping the boundary. I'm out of practice so don't know offhand what modifier keys might allow doing this without changing tools.

You can either disable the Comp Tool or just avoid clicking in the lower half of clips where its active.

Thanks for confirming. I suspected that might be the case. As a 'MIDI guy', my most common use for punch is simply to define an end boundary when recording hardware synth tracks, so punch range is often from zero to end of the project. I generally don't experience any issues starting projects at zero, and do it all the time, but I would like to be able to re-number measures from 0 for the case that a piece starts with a partial measure of 'pick-up' notes, or needs to give time for a synth to respond to initial controllers or patch changes.

fermata (n.) 1876, musical term indicating a pause or hold, Italian, literally "a stop, a pause," from fermare "to fasten, to stop," from fermo "strong, fastened," from Latin firmus "strong; stable" A fermata will usually be preceded by a rit. in performance, whether notated or not, but the fermata itself is just a pause/hold/hesitation. An any case, the fact remains that no more than one, fixed tempo is needed to control the timing from that start of one note to the next. As I said, give me any example in MIDI, and I will demonstrate. This is the one thing I agree with, and a solution is was given.

To be clear. The clip starts at time zero in my case as well, but the audio within it is late. PM'd the recipe, and posting it here so others can repro: - New project from Basic template at 125 bpm with ASIO buffer at 1024, 48kHz sample rate. - Insert a send on the metronome bus to a physical loopback from an out to an in (lightpipe in my case so the big buffer dwarfs the hardware latency) - Set the Input on the default audio track to that loopback input, and arm it. - Record a couple measures of click with punch enabled from 1:01:000 to 3:01. - Zoom in and note the click transients are all 1024 samples late = about 43 ticks at 125BPM. - Disable punch and re-record, and the clicks are right on the money. I have my Manual Offset dialed in so the recorded click on a phase-inverted track will null perfectly with the live metronome. Same result if I use the correctly compensated click recording on another track as the source instead of the live metronome. And same result at all ASIO settings - audio is one buffer late.

I'm still seeing the issue that audio is laid down one buffer late when Punch In starts at time zero. Punch in a measure later, and it's good. I have not yet tested to see what happens close to - but not at - time zero.

After seeing both you and Tom report that punches are early vs. my experience that they're late, I did another test with punch-in starting later in the timeline instead of at 1:01:000 as I had done initially, and got the same 'early' punch result as you. Will need to verify both cases work correctly when Noel gives us another update.