David Baay

This is an old issue that I reported way back in 2016. Last worked as expected in X3e.

Looks like a bug to me. Arming a Simple Instrument track by the shortcut should only enable MIDI recording as you expected - same as clicking the record arming button.

As Mark noted, the Absolute (SMPTE) runtime of audio clips will not be affected, but they will appear to change length because the Musical (M:B:T) time scale is the fixed, visual reference in Cakewalk. Importantly, however, the start time of audio clips is set to follow 'Musical Time' (M:B:T) by default, so any clip not starting at time zero will maintain its position in the M:B:T time and get audibly out of sync with clips starting at other times. In order to prevent this, you can either change the Timebase property of all audio clips to Absolute from Musical time before making any tempo changes, or (a better option in my view), use Set Measure/Beat At Now to change the tempo, which automatically preserves the Absolute playback timing of all clips (both audio and MIDI) in a project. To do this: - Set the the Now time cursor at measure Current Tempo + 1 with snap enabled. - Hit Ctrl+M to open the Set Measure/Beat At Now dialog. - Enter the Measure as Target Tempo + 1, Beat 1, and OK.

+1 for for all of your suggestions, especially an option to turn off auto-scaling (with a context menu option to 'fit' the scale one time), and an option to use only jump-type tempo changes.

Sounds a bit like what I've seen when attempting render direct to MP3 in real time. If rendering to MP3, definitely use Fast bounce. If rendering to .WAV either use Fast Bounce or try a more 'middling' buffer size like 1024 if the system can handle it. But could still be a plug-in; try disabling anything in the project that you don't use regularly.

So when do we get a to hear this piece? I'm a big fan of unusual time signatures, syncopation, counterproint, etc

You mentioned 'recording' tracks. If that means you're using synth recording and/or exporting with Fast Bounce disabled, you should try enabling it. Fast Bounce is an offline process that is largely immune to resource limitations, and frees the rendering process of the need to manage streaming output to the interface in real time. But it does use the realtime buffer size as a 'chunk' size for processing by default which can be problematic if it's small. You can override this by setting a non-zero value for BounceBufSizeMsec in the config file (AUD.INI). I've had mine at 20 (milliseconds) for a long time to avoid problems with certain synths that behave badly when rendered offline with small buffer size I usually run. Values up to 200 or even 300 are not unreasonable to try, and may improve render speed, but will use more RAM which might be an issue in your case with the high track/instrument count. One way or another, unless there's some interoperability bug between Cakewalk and EastWest, you should be able to resolve this with configuration or procedural changes that don't require disabling synth instances. FWIW, I also found this which might be applicable if one instance alone drops notes: "[The polyphony option is] in the main PLAY window (not the browser) at the bottom of paramaters on the left (starts with MIDI device, then MIDI port etc). It's set to 32 voices as standard which often isn't enough at all (for me) if you have many notes playing at same time (with release trails). I have mine set to 64 which mostly covers it."

Do you have a -6dB Center Pan Law set? It's under Preferences > Driver Settings > Pan law, but is actually a per-project setting..

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.