Noel Borthwick

This issue has now been fixed for the 09 release. I've posted a temp workaround in the other thread.

This issue has now been fixed for the 09 release. Thanks for your help sending a repro project file. BTW you can locally fix the issue by temporarily deleting and undoing the deletion of the Aux track.

Hi @sabo fx I looked at your dump file. This is definitely not an issue in the 07 release. What's happening is that the start menu is taking very long to populate the recent files list because it appears that some of your files are on a network drive. You can see below that the code is attempting to launch the start page. However it encounters this UNC file path: "\\192.168.178.21\workspace\Cakewalk\Projects\190901-Astatics\190901-Astatics.cwp" When it encounters this path we're trying to check whether the file actually exists by calling the Windows API PathFileExists. After that we attempt to read some meta data from the project file for the start page. The PathFileExists operation is taking very long and likely timing out. Is this network path still active on your system? ntdll.dll!NtQueryAttributesFile() Unknown Non-user code. Symbols loaded. KERNELBASE.dll!GetFileAttributesW() Unknown Non-user code. Symbols loaded. KERNELBASE.dll!PathFileExistsW() Unknown Non-user code. Symbols loaded. Cakewalk.exe!CStartPage::CopyUserData() Line 1008 C++ Symbols loaded. Cakewalk.exe!CStartPage::LaunchStartPage(HWND__ * hWndHost, int) Line 585 C++ Symbols loaded. [Inline Frame] Cakewalk.exe!CCakewalkApp::LaunchStartPage(HWND__ *) Line 452 C++ Symbols loaded. Cakewalk.exe!CCakewalkApp::InitInstance() Line 4463 C++ Symbols loaded. In general loading projects off a network drive via an IP address is not recommended since it could change if it isn't a static IP. This is the reason for your hang. This is also why closing a project hangs - because its trying to load the start screen. You can improve startup by turning off the start page in preferences or loading a bunch of local projects so that the UNC paths are dropped from the MRU in start menu. Let me know if this helps you resolve it.

@sabo fx if you haven't yet resolved it yet can you please capture a dump file from task manager while the app is in a wait state. This may shed some light into whats taking long. The dump file will be large so you will need to zip it and upload it to dropbox or some other file sharing service. When you do that send me a link to the file and I will look into it.

I don't think it's anything you are doing wrong. Most likely you are performing some specific series of operations that expose a bug. Do you recall doing a series of replace synth operations or deleting synths before you ran into the issue? I'll see if I can spot something in the code that might lead to this, but a recipe would be the quickest way to locate and fix the problem.

Can you check if the metronome samples are installed here: C:\Cakewalk Content\Cakewalk Core\Metronome And to verify the obvious - can you hear audio playing through the same bus if you insert some audio on a track and assign the output to the same bus that the metronome is using?

TBH I have never see heard of this issue reported before. I think your issue has to be very specific to a project or something environmental. Can you reproduce this in a new project? If you can, please contact me and I can run through some tests to try and isolate it.

You are using the latest release of Cakewalk by BandLab? Metronome should work out of the box assuming that audio playback is working. Are you using ASIO or WASAPI? Click the metronome icon on the toolbar and verify it is set up like this - see screenshot. Make sure the output is pointing to a valid bus in your project. By default its assigned to the "Metronome" bus.

Many keyboards these days do not have num pads so that wouldn't be very universal. Why not just assign "Edit | Select | None" to some key of your choice? You can assign num pad keys as well there.

The views menu checks the items when views are open (minimized or maximized), If you undock and close the inspector then the check goes away. Selecting the view from that menu toggles the min/max state. I see your point though. Edit. I see David Baay answered this sorry.

Exactly. We can't use ESC to clear something specific like selection. Its not standard Windows behavior and would be unexpected since users hit esc to get out of edit fields, dialogs and many other operations. It would be annoying to hit esc one extra time only to have it clear your selection.

@MarianoGF we managed to solve this issue for the 09 release. It was actually unnecessarily pre rendering the stretches during export. Unlike Radius, Elastique doesn't require the stretches to be pre-rendered so I have removed that. It fixes the clicks and also makes export much faster since its all processed in one go.

@jono grant I tried your project file and the automation does move when the edit filter is set to clips and lanes are collapsed. Are you sure that you have your track options "Select Track Envelopes with Clips" checked? See attached picture. If that is not enabled then it will not move envelopes when you drag clips. Can you verify this please? This should not have anything to do with Win 8 BTW.

The drop out occurs since its a runaway buffer allocation loop. The engine allocates buffers typically from a preallocated pool but when there are special requirements it will allocate memory when needed (within limits). In this case it never stopped allocating so the engine forces a dropout and releases all memory buffers as a failsafe recovery. The spike you see is likely the deallocation. This is mainly a failsafe situation and doesn't happen normally. Somehow in this circuit its not properly recycling buffers which may be the root issue here. These issues can be tricky to fix so it might take awhile to diagnose.

Yes as I expected its a buffer overflow condition. So it will keep allocating buffers until it hits a limit and forces a stop by triggering the protection fuse. We'll look into it and try and fix it.

@JL thanks for the report. We'll investigate.

Don't bother, I managed to work around this bug in older Arturia plugins. They go silent if we forward parameters to them when loading despite the plugin requesting the forwarding! I had to hack our code just for Arturia to avoid this.

If you had tons of 32 bit plugins this is expected. There are optimizations to cache the inventory preventing too many registry accesses.

@marled I cannot repro your clip selection issue. Can you post a short video or upload a small project that exhibits this? Is this with the smart tool or another tool?

The aux track defaulting to a hardware out is completely normal. It can't assign to the default bus since it would create a feedback loop. I tried recording the aux track for 10 minutes with both input echo off and on and could not get any dropout. Do you have plugins with delay in your project? It will be easier if you list steps from the start to reproduce this or supply supply a simple project where this happens. The logic is very dependent on the routing of a project so its important to know exactly how its set up. Based on the symptoms my theory is some internal buffer is overflowing leading to the dropout as a result of the overflow fuse firing.

@gmpcan you send me a simple project that has the issue? We'll look into it. Delete all the unnecessary tracks and synths and just keep the tracks required to repro the problem.

@Jeremy Jensen I was mistaken. I had an experimental build with some other stuff that isn't compatible with Arturia synths. I am not seeing any issues with Piano -V in the early access build. Which version of the synth are you running exactly. I have Piano V2 from VCollection 7 Version 2.4.1 and this is working fine here. I saved a project from an earlier release and opened it up in 09 and it plays fine. If you are still seeing this please reply to this post or contact me with a link to a project file that has this issue and I can troubleshoot further with you.

There is no substitute for plugin vendors fixing their own code so you should contact them about these issues and send them a project to reproduce it. Whether its fast bounce or realtime bounce there is no issue of CPU load since a dropout cannot occur during bounce. All fast bounce does is run the export as fast as the syths can render bypassing the audio driver clock. Realtime bounce does the export by running the transport. Thats the only difference.

@Jeremy JensenThanks for your report. I was able to reproduce this. This is caused by bugs in Arturia program management that I have reported to them. I have worked around these issues for the other arturia plugins but apparently the workaround doesn't work for this specific synth. I'll look into it.

Are you sure that this is actually a new issue to this months release? As Mark said some synths don't render data properly during fast bounce. Have you tried unchecking fast bounce to see if the render is accurate yet?