David Baay

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.

I copy is a separate entity by definition and can presumably be placed wherever you like, though I'm not sure the capability exists to paste a clip envelope into an existing clip...? This could get tricky when the target clip is shorter than the envelope. In any case, I would expect the original envelope should stay locked to the clip unless you delete or cut it, given that the primary intent of a clip envelope is to be part of the clip rather than part of the track.

Thanks, Mark. I understand all of the concepts. Where things go amiss is when you say 'Clip Envelopes are always Absolute Timebase'. That should not be the case for MIDI Clip Envelopes like Velocity Offset. Their duration should always be Musical Timebase, just like MIDI data. When you change the timebase of a MIDI clip to Absolute, it affects only its start time. I know this because I've been wanting an option to set MIDI Clip duration to Absolute for a long time. In the absence of this feature, MIDI Clip Envelope durations should always honor Musical Time just like MIDI data.

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

That looks like two bugs: First that the envelope should honor the musical timebase either way, but moreover that it should not be possible move Clip Automation independently of the clip.

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.

So it is a crash. If you have Nvidia graphics, you should look into the issue with OpenGL I linked earlier, and make sure your Nvidia drivers are updated. Although I only had an issue with the VST3.

They are still working on some latency-compensation-related stuff. There was still an outstanding issue with punch-recording from time zero. Leave punch disabled, and it should be good.

Weird. did they say what the fix was related to? I would still like to better understand the symptoms of failure, and which method you're using to insert the synth. Also, if it's the VST3, you might try the VST2. I ran into this issue with the Chromaphone VST3 more than a year ago, but if you're not actually seeing crashes, this probably isn't it: