JoeGBradford

Thanks - I'll stop looking for a setting to keep the window open then 🙂 Yes probably a bug which effects some VSTis but not others. At least the Union problem seems to be solved! Thanks again for helping

Good progress today - I checked over at the Soundspot page last night and there was an update to Union which included 'Global CPU Optimisation' I've run through loads of patches today without a problem 🙂 Also the Max Engine Load has peaked at around 108% rather than the 1,280% or so it was showing on old version. So fingers crossed that is that one sorted With Zampler I ran through the patches by clicking on the advance buttons on the GUI rather than using the scroll wheel on my APro 800 controller which is what I had been doing. No glitches and no huge Max Engine Load. Back to using the scroll wheel and the glitches reappear after around six patches - seems very weird but if that is what is causing the problem I'll stick to clicking rather than scrolling - though it is a bit of a pain! Not encountered this problem in any other synth that allows scrolling via controller. Thanks for your help. Hopefully the issues are resolved though it might still be worth me mentioning to the Cakewalk guys about the issue with Zampler By the way, on a totally seperate issue, one thing I find frustrating is that with some VSTi's the VSTi window is closed on loading the project even if it has been left open on saving previously - I can't see a setting to change this - is there one?

I'll try moving Zampler and it's patches onto the internal hard disc which I still use for other stuff and see if that solves it. At least I can rule that in or out then 🙂

Thanks for the help so far. Projects are on the external SSD - I replaced my internal HDD which previously had VSTs and projects on for the external SSD - I didn't really want to start fiddling round inside the case and thought with USB 3 and it being an SSD performance would be as good as previously I'm just using Windows Defender

My Zampler VST and presets are on an external SSD attached over USB 3. Union with which I have the same problem is a VST3 and so on my system drive in the default VST3 location - though I need to check where the presets for that are located when I am on the PC again tonight or tomorrow in case that is the issue if the samples are stored within the preset I have just been scrolling through presets on Voltage Modular and no problems with that - though I understand that is probably emulation based rather than sample based

Thanks Latest version of CbB and Thread Scheduling 2

Yes - this is one of the sets I have been trying. There is also a free set available through the free Beat Magazine https://sellfy.com/zamplersounds/p/the-trickster/ Much appreciated!

I tried this today but the same thing occurred - played a few different patches then stuttering started. As before if I changed focus away from CbB to Chrome and then went back to CbB and played the same patch again the stuttering didn't happen. Also if I turned the audio engine off and back on again, then play my controller keyboard, the stuttering stops - which will work as a temporary fix but a bit of a pain Another strange thing is that although the current Engine Load shown in the performance module stays within sensible figures changing patches causes the max Engine Load to rise up to over 1,000 percent - even when the patch changed to still plays fine

Thanks I'll try that tomorrow

Thanks ASIO 4 All is set at 2048 samples - the maximum available - it was the first thing I checked I did try WASAPI once but couldn't get it to work - presumably some incorrect settings - perhaps I need to try again

Yeah I know - sorry! Brain fade!

Sorry my answer to that should have been no - the audio engine is running but not the transport !

Which probably relates to my last comment?

Yes

Ah sorry - another revelation - if I go to chrome when I have had the stuttering and then back to CbB immediately stuttering stops!

I was though getting 14 late buffers when I hovered over the performance bar. However, and this is the first time I have noticed this, I didn't play anything whilst I was typing the above message and the stuttering has gone! Hopefully the above will give a clue as to what my problem is!

Managed to inspect Task Manager whilst running CbB with Zampler and changing patches to the point that it stuttered - non of the figures varied much from this

Thanks - I ran Latency Mon whilst playing different patches with Zampler and this was the result - apart from first couple of sections I am afraid I do not know what any of it means so would appreciate advice. I seem to remember when I tried task manager I couldn't look at it whilst in CbB but will try it again CONCLUSION _________________________________________________________________________________________________________ Your system appears to be suitable for handling real-time audio and other tasks without dropouts. LatencyMon has been analyzing your system for 0:03:28 (h:mm:ss) on all processors. _________________________________________________________________________________________________________ SYSTEM INFORMATION _________________________________________________________________________________________________________ Computer name: JOE-PC OS version: Windows 10 , 10.0, build: 18363 (x64) Hardware: ASUSTeK Computer INC., P8Z68-V LE CPU: GenuineIntel Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz Logical processors: 4 Processor groups: 1 RAM: 8172 MB total _________________________________________________________________________________________________________ CPU SPEED _________________________________________________________________________________________________________ Reported CPU speed: 3311 MHz Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results. WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature. _________________________________________________________________________________________________________ MEASURED INTERRUPT TO USER PROCESS LATENCIES _________________________________________________________________________________________________________ The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event. Highest measured interrupt to process latency (µs): 319.60 Average measured interrupt to process latency (µs): 5.353070 Highest measured interrupt to DPC latency (µs): 313.30 Average measured interrupt to DPC latency (µs): 1.594756 _________________________________________________________________________________________________________ REPORTED ISRs _________________________________________________________________________________________________________ Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal. Highest ISR routine execution time (µs): 155.443371 Driver with highest ISR routine execution time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation Highest reported total ISR routine time (%): 0.093462 Driver with highest ISR total time: dxgkrnl.sys - DirectX Graphics Kernel, Microsoft Corporation Total time spent in ISRs (%) 0.102324 ISR count (execution time <250 µs): 43400 ISR count (execution time 250-500 µs): 0 ISR count (execution time 500-999 µs): 0 ISR count (execution time 1000-1999 µs): 0 ISR count (execution time 2000-3999 µs): 0 ISR count (execution time >=4000 µs): 0 _________________________________________________________________________________________________________ REPORTED DPCs _________________________________________________________________________________________________________ DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution. Highest DPC routine execution time (µs): 619.970704 Driver with highest DPC routine execution time: ntoskrnl.exe - NT Kernel & System, Microsoft Corporation Highest reported total DPC routine time (%): 0.058823 Driver with highest DPC total execution time: rspLLL64.sys - Resplendence Latency Monitoring and Auxiliary Kernel Library, Resplendence Software Projects Sp. Total time spent in DPCs (%) 0.234657 DPC count (execution time <250 µs): 564512 DPC count (execution time 250-500 µs): 0 DPC count (execution time 500-999 µs): 3 DPC count (execution time 1000-1999 µs): 0 DPC count (execution time 2000-3999 µs): 0 DPC count (execution time >=4000 µs): 0 _________________________________________________________________________________________________________ REPORTED HARD PAGEFAULTS _________________________________________________________________________________________________________ Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution. NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit. Process with highest pagefault count: dropbox.exe Total number of hard pagefaults 3060 Hard pagefault count of hardest hit process: 2644 Number of processes hit: 29 _________________________________________________________________________________________________________ PER CPU DATA _________________________________________________________________________________________________________ CPU 0 Interrupt cycle time (s): 7.942864 CPU 0 ISR highest execution time (µs): 155.443371 CPU 0 ISR total execution time (s): 0.850463 CPU 0 ISR count: 43301 CPU 0 DPC highest execution time (µs): 310.951072 CPU 0 DPC total execution time (s): 1.614055 CPU 0 DPC count: 425836 _________________________________________________________________________________________________________ CPU 1 Interrupt cycle time (s): 4.920021 CPU 1 ISR highest execution time (µs): 59.606463 CPU 1 ISR total execution time (s): 0.000941 CPU 1 ISR count: 99 CPU 1 DPC highest execution time (µs): 203.456660 CPU 1 DPC total execution time (s): 0.024941 CPU 1 DPC count: 3152 _________________________________________________________________________________________________________ CPU 2 Interrupt cycle time (s): 7.101523 CPU 2 ISR highest execution time (µs): 0.0 CPU 2 ISR total execution time (s): 0.0 CPU 2 ISR count: 0 CPU 2 DPC highest execution time (µs): 619.970704 CPU 2 DPC total execution time (s): 0.292943 CPU 2 DPC count: 133004 _________________________________________________________________________________________________________ CPU 3 Interrupt cycle time (s): 3.623097 CPU 3 ISR highest execution time (µs): 0.0 CPU 3 ISR total execution time (s): 0.0 CPU 3 ISR count: 0 CPU 3 DPC highest execution time (µs): 121.637874 CPU 3 DPC total execution time (s): 0.020560 CPU 3 DPC count: 2523 _________________________________________________________________________________________________________

Thanks I'll check that out. Actually I may have already looked at that when it first happened but not sure

Thanks. I was wondering if it might be memory as it only happens after I have loaded several patches. Would the loading of several patches in short succession potentially overload the RAM

Hi all This is an issue I first encountered when using the new presets I bought for Union synth but is now also happening in Zampler that I have just got some free presets for via Beat magazine. After auditioning several patches I get a stuttering in CbB - close down CbB and open up again all is fine until I have scrolled through a few more patches then the stuttering starts. I've checked buffer size and processor load and all is fine there - as I say it only happens with some synths - it has occurred with Sampletank 3 previously but ST 4 has been fine. I'm on latest versions of CbB and Win 10. Using Thread Scheduling Config 2 i5 quad core CPU and 8 Gb of RAM. VST's are on an external SSD connected via USB 3.1. Using ASIO 4 All with onboard sound card (which has been fine for years though I know some people don't like it!) Any ideas? It's a bit frustrating having to close CbB down every few minutes when I use these synths! There maybe others with the problem but most I use have been absoultely fine

I was also one of the winners of Mike's last Amplesound giveaway and Jason at the company was really great to deal with

I don't think that is compulsory to win the prize (I could be wrong) but it obviously makes it easier to flag up when the winners are to be announced Anyway I'm subscribed to Mike's channel as his CbB tutorials are the best I've come across and he seems like a genuinely nice guy! I've learned loads of stuff from him

yes just the player unfortunately - I got excited for a couple of minutes when I first saw the deal 😉

Both Creative Sauce (Mike) and Robert's videos are excellent places to start for anyone new to CbB - and indeed anyone else who wants a reminder of, or introduction to, features of the programme. I have learnt lots from both of them!