Ben Staton

@Helene Kolpakova Thanks for the extra info and report. I did some testing and reproduced all 3 issues. So, to summarize: 1. Custom Browser width is not preserved if Browser is collapsed. 2. Custom MultiDock height is not preserved if MultiDock is collapsed. Not quite the same as the Browser width issue though, since custom MultiDock heights are preserved correctly, except when the MultiDock is maximized. 3. Browser width may become no longer adjustable. FWIW, all 3 are existing issues (ie. not regressions caused by last week's docking fixes). I think 1 and 2 are already logged (I'll check and log if not), and I'll log 3 so we don't forget them. No promises (it's late in the release cycle, and last minute fixes can be risky), but I'll also take a look and see if I can squeeze another fix or two in today.

@Herbert Miron @Kevin Perry Noel and I came up with a fix! Turns out it actually changed back in July with an unrelated fix.

I fixed a bunch of docking issues for this release. CbB is doing some extra work to restore the correct docking layout when loading a project/screenset/workspace, so it's not surprising if there are some minor, noticeable differences. To be honest, what I'm seeing in @Herbert Miron's videos (thanks for posting them, Herbert), although not ideal, doesn't strike me as being particularly bad or cause for concern. To me, it seems like a small price to pay to ensure your projects/screensets/workspaces look the same as you left them. But if you guys are seeing loading delays lasting more than, say, a second or two, then I'd like to see a video of that. It might be worth revisiting. Edit: I notice in Herbert's videos that the Inspector (left) and Browser (right) are both collapsed. I'd be interested to know if the same delay happens when you save the project with them both expanded. If not, that would be a big clue.

Yes, this should work correctly. I just did a quick sanity check. If I float the Synth Rack, then save and close the project, the Synth Rack is floating when I open the project again. Let us know if you still have any problems there.

I can confirm that I fixed this late last week. Thanks for reporting it and for letting us know it's now working for you.

Re issue #2 reported above by @Helene Kolpakova, we're currently testing fixes for that and some related issues (see below). All being well, they should be included in the next release too. Browser/Synth Rack/Help Module docking fixes currently being tested: 1. Browser would sometimes open as expanded even if it was collapsed when the project was saved. 2. Help Module or Synth Rack were docked at the top (above Browser) even if they were below it when the project was saved. 3. Browser docking layout wasn't restored correctly on project load if the Browser was collapsed. This resulted in odd layout appearance and/or incorrect Browser/Synth Rack/Help Module order.

I think we made FX bins scrollable with the mouse wheel post Platinum, so technically it's by design. That is, if the mouse is currently over an FX bin, mouse wheel scrolling will scroll the FX bin, not the parent view. It's useful since you can only see a couple of plugins at a time at default track heights. There might be some minor inconsistencies with the timer Noel mentioned, and we could potentially make it smarter, but it's basically working as designed, and that explains why it's different to Platinum.

There's actually a 64 bit version of Spy++ in the same folder as the 32 bit version. Visual Studio opens the 32 bit one by default (via Tools -> Spy++). Since CbB is a 64 bit application, you need to run the 64 bit version of Spy++. On my PC it's here: C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\Tools\spyxx_amd64.exe Give that a go and you should be able to view messages.

Very strange! I pinged Fractal Audio tech support and asked for a dev to contact me. Maybe we can work together to figure out what's going on.

We're looking to improve accessibility in Cakewalk soon. Work has already begun behind the scenes, but there's lots to do. It may take a while, but big improvements are coming. Thanks for bearing with us in the meantime.

FWIW, we can't reproduce it here. I also checked the code and it doesn't seem to be doing anything unusual or CPU intensive at all when moving the mouse over track names. Indeed, moving the mouse over track names actually does significantly less than moving it over some of the other controls nearby. Are there any other clues you can give us?

@torhan Thanks for the report. Unfortunately, we can't reproduce it here, but we're aware that issues like this do happen in rare circumstances. If you see it again, please would you post a screenshot showing the entire Cakewalk window? That can often give us clues that a more localized screenshot can't, such as the general layout of all views at the time it occurred. Thank you! In the meantime, resizing the window (or un-maximizing it and then maximizing it again) usually fixes it.

@Herve Maratrey I just PM'd you a link to a new installer. Hopefully, that will fix your problem. Please let us know how it goes. Thanks again, Ben

@Herve Maratrey We're currently testing a fix for this, which looks very promising. Is it OK if we send you a new build to test?

I'd also like to know which languages you have Windows and Cakewalk set to. It may be relevant.

@Herve Maratrey Please would you also check the Arranger by opening the 'View' menu in the Track View, and then choosing 'Arranger Track Show/Hide'? We're wondering if that also causes a crash for you. Thanks!

Hi @Herve Maratrey, Thanks for the report. The crash dump suggests there might be an issue with DirectX on your PC. Firstly, I would make sure that your graphics driver is up to date. If that doesn't fix the problem, you could try running dxdiag, which is the 'DirectX Diagnostic Tool' that comes with Windows 10. It might highlight any DirectX problems and help you to resolve them. Failing that, dxdiag has a 'Save All Information...' button at the bottom that will save a file containing information about your DirectX installation. If you send that file to us, it might give us some clues (check it first, to make sure you're OK with us seeing the information it contains). Please let us know how you get on. Thanks again, Ben

Thanks for the report. This bug has been reproduced and logged. No guarantees, but hopefully we'll get to it soon.

Hmm, this is a tricky one. Cakewalk literally does nothing at all to change or ignore the Windows scaling setting. It neither opts in nor out of it. Essentially, it just throws its hands in the air and says "Hey Windows, I know nothing about high DPI, so you take care of it!". Do you by any chance have multiple monitors? If so, do they have different resolutions? Do you always run Cakewalk on the same monitor? Do you ever run Cakewalk on another display, whether it's temporarily plugging in a different monitor/TV, or by running it remotely (via Remote Desktop or similar)? Do you change the Windows scaling setting occasionally (nothing wrong with that, but it might be a factor)? I'm also wondering why you're running Cakewalk with admin permissions all the time, which shouldn't be necessary. If Cakewalk is somehow affecting it (again, I fail to see how, but stranger things have happened), running it without admin permissions might prevent it from doing so. If anyone else is running into this, please let us know. I'd like to get to the bottom of it.

Nice idea, but I don't think that's the problem. While we use some CJ stuff, most of the UI is built using other technologies, and this seems to be an app wide issue.

I'm struggling to think how CbB could change your high DPI scaling override setting. I know we aren't doing anything out of the ordinary. On start-up, CbB just tells Windows to handle scaling on its behalf. I wonder if Windows is trying to be 'clever' and is changing it because it thinks it knows better?! A while back, I came across a plugin that was calling Windows DPI scaling functions, which it definitely shouldn't have been doing under any circumstances (it's the hosts job to worry about things like that). Maybe one of your plugins is misbehaving? That might explain it. I did some Googling, and app compatibility settings (of which high DPI scaling is one) are stored in the registry here: HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers @jono grant If you're familiar with the registry, please would you send me a screenshot of the Cakewalk.exe entry in there? You might want to try deleting it to see if that makes any difference (at your own risk, of course). FWIW, I tried setting the high DPI scaling override and then deleted the corresponding registry entry with no ill effects.

Hi Jono, That's very odd. I haven't heard of anything like this, apart from maybe one guy who had to set some custom DPI settings or CbB would crash on startup (which should now be fixed anyway, at least in the latest Early Access release). When you say "I'm continually going in and having to set the scaling over and over again", what is it that you're doing specifically? Are you going into Windows Settings to set it to 150% again, or something else? Also, what version of Windows are you using? Thanks, Ben

A fix for this will be in the next release!

I'm working on a fix. In the meantime, using Alt+Tab to switch to another application, and then going back to Cakewalk, seems to 'un-stick' the mouse so you can continue working.

Thanks for the reports. We've logged this issue, and I'm investigating it now. When it happens, does the little zoom window remain visible on-screen, or does it disappear but the mouse is still stuck? Thanks!