Tez

Mr @Colin Nicholls, I just thought misery loves company... ? Meanwhile under Windows 1903 & CbB 2019.09 I'm getting the occasional dropout while doing some activity in the track pane, no audio (play stopped, no audio input), no midi input (keyboard off) and no midi editing and the reason code is so far (1) : "Audio processing took longer than the buffers allotted time slice", which is a puzzle, unless "Always Stream Audio Through FX" being checked has something to do with it and... Dum ta dum dum... Aux tracks, of which there are several, but only being fed by synth outputs that have no midi inputs assigned and echo off on those synth tracks. So my question to you is do you have Aux tracks in your projects that get or got the toast?? I'm sure you've been following forum "dropout saga" as I have ?...

@Noel Borthwick Here's a link to the crash dump which just occurred, it's a "dropbox" link: https://www.dropbox.com/s/rjlngbt805afzj5/_09162019_214556.dmp?dl=0 I just wanted to get a handle on what was happening here, and hopefully using Rapture Pro doesn't have any negative effects in my projects, other than this random crash. Many thanks T...

@Noel Borthwick Thank you for looking into this, it might be my old O1/Wpro keyboard, that's the 1st suspect, hope it's not the Fastlane USB midi interface, I have the latest driver. When you yanked the USB cable did it cause an audio dropout? Oh and I found another "Windows 10 May 2019 Update version 1903" known issue, namely "Error Event 455, ESENT" errors occurring with high frequency for Logging, due to a missing folder, and there were a lot... Fixed it now, don't know what side effects this might have caused if any.

As I said before in that instance "The only way to clear these greyed keys was to reboot CbB." It may be on that on some occasions this occurs one could clear the keys without restarting CbB by some other method, but most times no, pressing play doesn't do the trick... Thanks for looking into this! And once again pretty please can you shed some light on Rapture Pro sporadically crashing CbB with an access violation, if you have any knowledge on it, it would much appreciated... Yes indeed I have... The worst consequence of doing this is, if the project wasn't saved before doing a "Reset MIDI", some synths which have specific parameters set either arbitrarily or precautiously via a preset can get zeroed out and also doesn't do the trick... ?

@Noel Borthwick Hi, This is an image of the random piano keys that became greyed out: g#6, c5, g#4, c0... The thing to note is "c0", no note scored in the PRV was c0 and my midi keyboard doesn't have a c0, the lowest note is e2. I was editing the volume automation in the track view on an aux track when the audio dropout toast popped up, the audio engine icon was indicating 'stopped' that is not blue. I then checked the PRV and found the greyed keys, at the time 2 of the midi tracks were assigned to a midi input, but only one had input echo on and the keyboard was switched on but not being used. The only way to clear these greyed keys was to reboot CbB. The only way I'm aware of, that a PRV piano key turns grey is if there is a midi track assigned to an input source and has received a "midi note on" and it will stay that way until a "midi note off" is received... So how is it that these keys became irreversibly grey? It's a mystery! Mysterious or not it's become irritating as the project has be saved and CbB has to be restarted. There's question on which you might be able to shed some light. On opening this project which has an instance or Rapture Pro, it sporadically crashes CbB with an access violation caused by the plugin, I'd say about 1 in 10 times. Is this a known issue with Rapture Pro, since it also occurs with Splat?

Play a chord of random notes say on a midi keyboard and the PRV piano keys corresponding to the notes turn grey until a "midi note off" occurs for each key and then it reverts to its key color... In the case where the random chord was heard as I described in the above post, the corresponding keys for the notes heard turned grey and stayed that way and only rebooting CbB would clear them back to their initial key color. So it feels like some midi buffer spewed out a bunch of random "midi notes on" and no "midi notes off" & that got the PRV piano keys stuck, as I mentioned above the the random chord continued sounding until it decayed, that is no "midi notes off". When this happens, and with any luck it won't since fixing the cpu spike, it's sporadic & not reproducible, but if it happens I'll take a screenshot! If I recall after the dropout the audio engine icon remained blue...

I don't know if this has any bearing but here goes... In my project in the tracks view I've got 3 synths (primary output & midi tracks) , 2 with midi input set, 1 with input echo on. 3 aux tracks associated with 1 synth that has no midi input set.. and a bunch of FX plugins. In the PRV I was editiing the midi track for the synth set with input echo on, which was shown selected in the PRV & the track view. On switching from the PRV to the track view the dreaded audio dropout toast popped up which I ignored... Now this is the weird part, at this point I stepped away from the DAW to briefly take care of something else, after a few minutes I heard a chord of random notes from the selected synth with input echo on. I returned to the DAW stopped the audio engine and on restarting it heard the decaying chord notes and in the PRV a random set of piano roll keys were greyed out and could not be reset! Fortunately I could save my changes & rebooted the DAW to clear the greyed out keys. This feels like something strange is going on in the output stream, quite what I've no idea.. Any suggestions?? Monday FYI just found out the latest w10 monthly update "August 30, 2019—KB4512941 (OS Build 18362.329)" did do something! It caused a 20% cpu spike due to a cortana bug, because I had searching the web from Windows Desktop Search disabled. It's enabled now & the cpu is back to normal, will see if this bug was affecting the dropout frequency, who knows what was behind the spike & what, if any, side effects were caused...

Very interesting Mr @Colin Nicholls ... Unfortunately it's not a viable solution pour moi, and the idle dropout suggests something else is going on. I'm wondering, have you tried a project with audio only, that is no synths or FXs? In the past the only time I'd get one of these recurrent sporadic dropouts with splat, as I recall, was a project using "Rapture Pro". I mention this because on loading a Rapture Pro project sometimes Splat and now CbB will instantly crash with an "Access Violation" C0000005, caused by Rapture Pro, which I imagine is some pointer holding a bad address, and on a restart the project loads fine, which suggest an issue with the synth plugin, also sporadic. The current project that's giving me the toasts grief also has an instance of Rapture Pro, so is it possible a wayward synth is the root cause? Just a thought... Oh and with all due respects to Mr @Noel Borthwick, as for "I wouldnt worry too much about that toast", when it does happen on several occasions the PRV shows a random selection of greyed out piano keys, which sometimes can only be reset by closing and restarting CbB...

Stoopid question ? How do you create the "at sign" black background member reference... I've not ever used that anywhere??

I keep backups of the prior "Cakewalk Core" folders, you may or may not already know this but if not check out this post My 2019.05 backup is a composite of the 2019.03 hotfix full install, and the 2019.05 update, I suppose there is or was a full installer...

Call me crazy but... Since 2019.07 I get a higher frequency of the sporadic "audio dropout" toast when editing events, in the PRV, not in the PRV and no audio or midi activity (the keyboard was switched off). The last time it occurred though, was at the start and at the end of a "bounce to tracks", this messed up the start of the rendered audio... On initiating the bounce, up popped the toast and I canceled it without saving the partial, restarted the bounce and let it finish and the toast appeared as stated, start and end. I had to close CbB and after a restart the bounce was fine. I appreciated Noel's remarks but it does feel like something's amiss, a bad pointer, memory leak or something... I don't know if the latest w10 monthly update "August 30, 2019—KB4512941 (OS Build 18362.329)" did something?

The key entries I found at the update time were: [2019-08-31 15:21:29.029] [info] Checking for update [2019-08-31 15:21:29.121] [error] Error: TypeError: this.app.whenReady is not a function the rest in the log I looked at is code entry points (+ corresponding personal info) ... Personally I happy to download the exe & run it manually, that's 99.9% likely to work, if it's predecessor had no problem, rather than rely on auto-update code to do the job, and going forward that's just what I might do... ?

5.0.6 works fine here... Don't use BA on startup, so had to launch the assistant which issued an update notification, but on selecting update, presumably a self update, it failed, followed by an instruction to download BA (bandlab-assistant-windows-latest.exe) and manually install via the exe, which is ok... Just remember to run as Administrator. Was this your experience, or was this just a glitch going from 5.0.4 (which was my initial BA install) to 5.06, if anyone knows??

Patch Tuesday is precarious... I've had various settings weirdness after an update restart, some vanish on a reboot, others not... One mo' thing to add to the check list, post update ?

Good Catch... Just checked and yup, Game Mode was on! When did you notice this??

FYI... My current project has 4 instances of Kontakt, 1 with 10 instruments loaded, 1 with 3 and 2 each with one, separate outputs & midi channels. The single instrument instances were breakouts from the multis, as there seemed to be performances quirks for those instruments, for unknown reasons, but I suspect it might have been due to a combination older libraries (Kontakt 2) with current ones, so there may have been some compatibility issue, or a scripting issue who knows, as also a chunk of midi CCs are used for all of them...

Thanks. That was my guess, hence the question... As to external audio, that's not an issue as there is none for my midi projects. The issue for me is Kontakt, on a fast bounce it might glitch, midi events sometimes get lost. I 'll have to experiment to see if there's an audible improvement on a higher than the default buffer size, not that the render sounds bad, but it's the potential for lost midi events such as cc data that doesn't easily get noticed unlike a missing note which can happen even with fast bounce unchecked.

For an ostensibly midi project, on a “Bounce to Track(s)” when “Fast Bounce” is unchecked, does the “MIDI Prepare Buffer Size” value make a difference for the render??

If you’re using “Native Access” to update Kontakt which is the prescribed method, under the user icon’s (that’s the little head & shoulders) drop down menu is “preferences”, click on that and see the install vst paths that Native Access uses... Then check CbB Utilities>Cakewalk Plug-in Manger>VST Instruments (VSTi) & locate the “Kontakt” registered plugin and select to see it’s location... Copy the new to that location. That’s essentially what I do, as I keep all my NI stuff in a specific location...

see this topic it's probably CbB zeroing the controllers...

Indeed... And it seems recording is only way to see the waveform behind the envelopes after stopping the recording. Just checked a track with vst automation and the waveform preview has the same issue as the bus. This was for a stereo track with the double waveform, don't know if it's same for a mono?

No it's not just you... But going forward for this & other reasons I'm taking Mr. Scooks advice...

Terrific... jBridge is not free & the demo's limitations make it only useful for a review, be nice if there's a fix for BitBridge. Meanwhile is there any other free alternatives out there someone could recommend??

I loaded the test project in the final Splat 64 bit, originally created for final Splat 32 bit. I can confirm that, yes indeed, in spite of the preset indicating the one that was saved, it was in fact the 1st in the preset list “Bass Gratification”, and re-selecting the checked preset that was originally saved will restore it. Re-saving the project under a different name from Splat 64 bit made no difference on the Splat 64 bit reload. This was with BitBridge, so it seems that whatever the preset parameter is, is not being recognized or applied to the vst via the bridge on loading in Splat 64 bit, yet the Splat 64 saved version opens in Splat 32 bit without any problems. It might work with JBridge but that I can’t test.

Interesting synth... I created a test project for final Splat 32 bit, using two (2) instances of “Prodigious Synthesizer V1.2” each setup with a different “Prodigious Factory patch”, recorded a midi sequence for each midi track per instance. Also loaded an instance of AD2 and setup a midi drum sequence and saved and closed the project. On reloading the project all returned as saved no problems! Since this is a 32 bit synthedit VST, I hesitate to use it in CbB, having had problems with some 32 bit VSTs and BitBridge, causing crashes in Splat 64 bit. I assume your issue is in CbB, who knows it might be whatever bridge you’re using in conjunction with Prodigious, or another plugin in the mix? And, I always run the Splats & CbB as an administrator...