MIDI notes dropout

[Robert Glaser]

I have a large file (64 tracks). The setup is a full orchestra using EastWest Samples. Tracks are grouped by an instance of instrument track and 8 MIDI tracks per instrument with each MIDI track with each MIDI track having it's own channel (1,2,3--8)

Sometimes, certain tracks drop specific notes. on each replay it is the same notes that are dropped, they are not random. It could be the second Eb5 in a melody line in the first flute for example. That same note will be fine in the same track at a different point. There isn't overlap, as I have checked (even though it is a polyphonic instrument with "RoundRobin" playing.) I can rerecord it and during recording it will be fine, but after the rerecording, it may be a different note or notes that drop out. There may also be notes in the rerecording that overlap for legato that play perfectly well. There are also cases where it may be the first note in a melody line after many measures of rests/'tacit'.

Even a 50 tick space between the end of the last note and the beginning of the note in question doesn't solve the problem. Freezing the set of MIDI tracks for that instrument group (of 8 MIDI tracks) doesn't solve the problem either.

This happens with some of the woodwind instruments and some of the brass instruments. I have not been able to identify the problem. I have tried switching to different samples to get it to work, but that doesn't seem to have any affect.

Currently using the 2021.04 version of Cakewalk.

[David Baay]

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.

[Robert Glaser]

The MIDI Prepare Buffer size for this project is 250ms. I tried setting it at 1000ms to see if there was any improvement. The problem remained.

There are no effects on the tracks where this happens.

[David Baay]

On 5/10/2021 at 8:12 PM, Robert Glaser said:

This happens with some of the woodwind instruments and some of the brass instruments.

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.

[Robert Glaser]

Thanks for the help and suggestions. It pointed me to a solution and I have solved the problem.

It was due to either the load on the system or excess MIDI data in the stream. By taking the project and eliminating all but one instrument with the 8 individual channels/tracks  associated with it (9 tracks with an instrument track and 8 MIDI tracks) and playing it back. This played perfectly well.

Although I'm using a Quadcore Xeon processor, SSD, (2) and 64Gb RAM, the work is 45 minutes long and has 63 MIDI tracks split to 17 virtual [EastWest] instruments. It takes 7 minutes just to load the Samples to RAM. Interestingly, the processor and RAM monitors in Cakewalk never register very high usage, even at peak MIDI stream bandwidth.

This may make for a tedious process of mixing.

I knew that there was no problem with the samples as all notes would  play. The dropouts would appear in certain sections and if replayed/rerecorded, different notes would dropout.

Edited May 18, 2021 by Robert Glaser
Left out the "Thank you"

[David Baay]

 

On 5/10/2021 at 8:12 PM, Robert Glaser said:

Freezing the set of MIDI tracks for that instrument group (of 8 MIDI tracks) doesn't solve the problem either.

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."