Ben Staton

Regarding mouse cursors, there are some we've yet to update for high DPI. It's logged and we'll get to it in due course.

FWIW, obviously they look fine at 1080p, but they also look OK (not perfect, but definitely acceptable) at 4K too. This is because 4K is exactly 4 times the resolution of 1080p, so the scaled up cursors still look sharp, albeit a little pixellated, because one 1080p pixel equals exactly four 4K pixels.

1440p, on the other hand, doesn't match up neatly with the old cursor size like 1080p and 4K do. Since 1440p can't scale them up perfectly by whole numbers, it tries to fit them in between the pixels, which makes them look blurry.

It's definitely something we should address. Thanks for the reminder.

5 hours ago, sjoens said:

A new graphic issue:  When opening a project saved in CbB, the Inspector bleeds thru from underneath MultiDock views.  

Does this happen every time you open the project? If so, please can you PM me a copy of it?

2 hours ago, sjoens said:

Happens when:
17" 4K laptop = 3840x2160 @ 250%  AND  29" LG Monitor = 2560x1080 @100%  AND Sonar is on the LG Monitor

Does not happen when 17" 4K laptop = 3840x2160 @ 100%  AND  29" LG Monitor = 2560x1080 @100%  AND Sonar is on the LG Monitor
However, this scale makes everything on the 4K too small to see.

 

In testing this I also found the top control area of Track View including the time ruler slowly disappearing, but have not been able to reproduce it:

Please can you send a screenshot of your Windows Settings > Display screen, showing the layout of your monitors. It can make a difference when multiple monitors are arranged side by side, on top of each other, or any number of different alignments given that Windows is very flexible in that regard. Thanks 🙏

@Helene Kolpakova

I fixed the 3 remaining Browser and MultiDock docking issues (see a couple of posts up).

Fixes for issues 1 and 2 will be included in the upcoming release. Unfortunately, the fix for issue 3 will have to wait for the following release. It's too risky to include at the last minute (needs a full beta/EA testing cycle).

Thanks again for your thorough reports.

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

38 minutes ago, Kevin Perry said:

The Track Inspector does definitely take longer to be drawn now than in previous versions (I also checked with SONAR Platinum with a very small - 5 track, 2 or 3 effects - project and TI appearance is instant vs. ~0.5 seconds in the latest EA).

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.

On 11/4/2022 at 8:34 PM, GreenLight said:

Impressive work in this thread, great job @Helene Kolpakova!

I'm sorry if I don't understand the obvious from the above - but will the Synth Rack state now be remembered if it is floating? I always have to re-float it...

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.

On 11/5/2022 at 10:47 PM, Herbert Miron said:

This issue has already been resolved in the new update, as far as I can see.

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.

5 hours ago, ZincT said:

I haven't found any other apps that are misbehaving mouse-wise and the issues only started after upgrading Cakewalk to 2022.06.
I will see if my spare wired mouse works any differently and also maybe try rolling back to 2022.02.

Thanks for your help.

Thanks for the report. Seems to be an isolated incident so far, and I can't think of anything in this release that would cause such behavior.

I saw your post about not being able to do a screen capture. Is there any chance you could use your phone to capture it instead? Also, are you running any third party software that customizes the appearance of Windows and/or Cakewalk, and/or influences mouse behavior somehow? If so, it's worth disabling it and trying again.

If you do eventually rollback to 2022.02, I'd be interested to know if that fixes it too.

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.

2 minutes ago, Anikin_VI said:

When I use Microsoft GS Wavetable Synth, the result is the same! I don't know what is it on all my computers.

Oh, interesting. Same for Microsoft GS Wavetable Synth? It seems OK here, but I'm using Windows 10 English:

What language is Windows using? We might be able to duplicate it if we know the OS language.

39 minutes ago, Anikin_VI said:

Here are other screenshots (MME - all texts in English, UWP -  all texts in native language, encoding latin1, I think):

As far as I can tell, CbB simply shows the name reported by the MIDI device driver. I also verified that our UI is capable of showing Unicode characters correctly in this context (I even tested it with emojis!). I can't reproduce it, but then we only have UWP MIDI devices that return plain ASCII/English names.

It's possible that the Virtual MIDI Synth software you're using is returning the name incorrectly when in UWP mode. Does the name show correctly in other software?

ps. Thanks for taking the time to share those screenshots.

4 hours ago, Anikin_VI said:

One more problem: When I select UWP Driver Mode, the Preferences Window looks as the picture.  I think that UTF-8 encoding must be used hear.

Thanks for the report.

Do you see the same thing if you change 'Driver Mode' to 'MME'? Also, do you know what that port name should actually be? If you can paste it here, then I might be able to reproduce it.

19 hours ago, 뮤직벙커 said:

Hello~

I've only been using Cakewalk since DOS Cakewalk. I'm still using it now, so thank you very much.
When using Export Audio, the dialog box has changed since 2021, and it has become very inconvenient for me, who writes Korean.
There are some countries that use double-byte characters, such as Korean. I do not know the country of the other 2 bike characters, but there is an error in Korean.
When typing, the letters are hard to see, so it is very difficult to type the file name.
I checked the error condition in the attached JPG file. There were no errors in the old-fashioned dialog box that Cakewalk used from the beginning. After changing to a stylish black design, there was an error in the text input. I would appreciate it if you could modify it so that it can be used freely in Korean in Korea.

Thank you.

Hi,

Thanks for the report. Does the problem only happen while editing text? In other words, does Korean text display correctly until you start editing it? Your screenshot suggests that's the case.

If so, there's a known issue with our text editor control which doesn't draw Unicode text correctly. You can still enter Unicode text, but it won't display correctly until you finish editing. That's something we hope to fix in a future update.

If that's not it, please let us know and we can investigate.

Thanks again,
Ben

1 hour ago, Panu Pentikäinen said:

I tested Spy last night but for some reason I was not able to log messages.
Might need some help as I've used that tool last time a decade ago..

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.

3 hours ago, lm3783 said:

OK. Removing EnableWin10DPIAwareness solves the issue. Thank you!

Great, thanks for letting us know. I think it's time to remove that setting. It was only ever meant to be experimental/opt-in anyway, and yours isn't the first issue we've seen with it.

4 minutes ago, lm3783 said:

EnableWin10DPIAwareness=1

Aha! That might explain it. Please try removing the 'EnableWin10DPIAwareness' setting in Preferences -> File -> Initialization File, and then restart Cakewalk.

6 hours ago, lm3783 said:

Bug report: PC2A is not shown properly with High-DPI scaling.

Here is what I got with 300% scaling. 

Thanks for the report. I can't repro @ 300% here though (on a 4K monitor), so some more info would be useful please.

Does it always happen, even if you restart Cakewalk/Windows? Are you using the latest version of Cakewalk? What's your monitor's native/current resolution? Which version of Windows are you using? Do you have a custom theme enabled? Are you using any 3rd party apps that customize the appearance of Windows (some are known to cause issues)? Do you have any special options enabled in Preferences -> File -> Initialization File? Are your graphics drivers up-to-date? A screenshot of your entire desktop might also be helpful.

Edit: It might also be worth reinstalling PC2A just in case.

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.

4 hours ago, Ben Chase said:

I'm having the opposite experience of a lot of other folks. The context menus for plugins are gigantic for me, even though my Windows display settings are set to 100% and 1920 x 1080, both of which are the recommended settings for my monitor.

Thanks for the report. I'm working on some fixes in that area, so I'll PM you to discuss shortly.

4 minutes ago, Toy said:

When "Windows 10 high DPI rendering option" is enabled, the display of plugins of some manufacturers is distorted.
I tried "EnablePluginMenuFix = 0", but it didn't work.
※Ver. 2021.04 build 144&155(JP) | DisplaySize 3840x2160 125%

Checked owned plugins.
- Melda Production: All owned plugins.
- United Plugins: "Royal Compressor"
There may be others, but not all have been checked.

When "Windows 10 high DPI rendering option" is disabled, there is no problem.

Display example.

 

Thanks for the report. I'll investigate.

6 hours ago, apt said:

It is build 155

Thanks for verifying. Please would you try adding the following option in Preferences -> File -> Initialization File:

EnablePluginMenuFix=1

Then restart Cakewalk and let me know if your plugin menus look any better.

To be clear, that option should be enabled by default, so I'm not expecting it to make any difference, but I want to make sure it's enabled to rule out anything unexpected.

Many thanks!