Noel Borthwick

@azslow3 thanks. Its a complicated problem. We will likely be extending the Microsoft accessibility framework that we currently use. We’re aware that our current implementation falls short in several ways. If you are interested in providing feedback on this we will be happy to share a build with you when we get closer to this.

Thats great to hear. Although a new install typically performs better initially so some of that could be attributed to this. If you can it would be good to see some comparisons running a session at low latency with the same audio hardware. I said borderline While forced obsolescense is never a welcome thing, in my experience many laptops tend to start falling apart after 4 years of heavy use. Ive seen it with many laptops over the years. My most recent to fail is the Surface Pro 4. Since over a year ago the touch screen started malfunctioning and other weird hardware related things started happening. I had a HP some years ago that literally melted parts of the MOBO internally! Heavy laptop users tend to upgrade every 4-5 years or so because of things like this on both on Mac and PC. Also laptop CPU’s tend to get obsolete faster. This is why I would be less surprised if Laptops are not upgradeable - in fact the manufacturers do not support the BIOS for upgrades after a few years.

If you narrow it down please send us a project to try and isolate it. Thanks!

For clarity here - (without arguing the point further) The ONLY change is using numbers instead of the Left Right Stereo convention and being consistent about this everywhere. Here is what it was before: The Left Right and Stereo were Cakewalk specific prefixes because we group everything into stereo ports by default (something many other users coming in from other DAWs dislike btw). And here is the same I/O listing now: Compare the two - many would say that the new display is cleaner and easier to understand. We changed that to something more useful like 1, 2, 1+2 which is pretty much the de facto standard for naming in other applications. Left right and stereo are completely implicit here because they are in groups of three and the numbers automatically show that in a more compact way. We did the same to all I/O's for devices and virtual instruments so that new users have a consistent user experience.

I'm sorry you find this silly but I think its due to your refusal to see that there are other points of view where this is useful. It has nothing to do with a programmer point of view since in fact these suggestions did not come from developers. I'm not sure how many other DAW's you have used - please take a look elsewhere. Pretty much most others exposes the hardware device channel index in the UI in some form or another so if anything us not doing it was the non standard feature. I posted a screenshot of Windows but we did check how several other prominent DAW's do this. I'm not going to post screenshots here but you are free to check them out for yourself. Keep in mind that we focus on features that need to be intuitive to users coming from other platforms and with different experience levels. Occasionally this means that we have to change how we do things in ways that existing users may not initially like. Its an unfortunate part of making progress. I think we're beating a dead horse here however. As I said I understand you don't like it.

Its not confusing to me at all. It shows me very clearly that Aux L is the 5th physical input on your device and that you have hardware inputs 1-4 disabled. These are the Fantom VS inputs right? If you hadn't disabled 1-4 you would also see them listed in the dialog as 1-4 which would perhaps make more sense visually. Irrespective its showing extra identification channel info that you would not have seen earlier that's all. This data can be very useful for troubleshooting esp for new users who couldn't correlate what they saw in the menus with the actual hardware before. However I get your point that you don't like seeing numbers that don't correlate to the numbers reported by the device despite the fact that the numbers reflect reality

There is no loss of information in the menus, in fact there is a more actually useful information now than previous versions. All it did before was show the first channel name for stereo pairs. This was very confusing to many new users who interpreted this as missing inputs. We do hide the prefix automatically for port names. They are only shown in menus (as mentioned above even with friendly names there are use cases for seeing channel numbers). 3+4 is much more informational than (L+R) since a stereo pair is implied but the channel number wasn't visible before. i.e we haven't really added anything extra by replacing the L/R with the actual channels in use. We're trying to get away from excessive options in the app...

When using friendly names the prefixes are not shown in the port name fields just in the menus. Channel indexes are still required in order to correlate arbitrary driver names (some drivers have terrible names) to actual hardware channels. For example irrespective of the driver names if you have some I/O's deselected in preferences the channel prefix allows you to exactly know which input or output is being referenced. Unfortunately there is no one size fits all solution because the names differ drastically across various devices and even across different driver modes. The indexing ties it together in an attempt to make it more universally understandable.

As Jon mentioned its been a user request forever. Literally every audio application lists devices by their enumerated channel index. Here is how windows enumerates my RME device: As you can see there are channel indexes listed in the enumeration. We do this in an identical way but have generalized this to all ports software and hardware since the same issues exist. The fact that some drivers choose to label their ports differently is completely out of our control since there is no way to retrieve that information. Most drivers label their I/O's serially and then have a more descriptive string that shows something like Mic or Line. The channel indexes are simply the identifier of the physical hardware mono channel the exposed list of inputs and outputs. In a multi I/O device it tells you exactly which I/O you are using. Here is how it shows for me in preferences. I can see that the inputs go up to 30 channels and tally with the labelled values for all the analog ins. For AES and ADAT they internally label them differently which is completely normal. ADAT 1 is physical output 15 and so on. What is also new is that we display the actual left and right channel names for input ports. Previously you would only see the left channel listed.

Um I'm not what you used to translate my response to you but it wasn't anything like above. I responded to your questions asking you what you found missing from your workflow to understand why you didn't like it. Nothing more than that.

The plot thickens. All this for mandatory hardware virtualization. 🤯 https://www.zdnet.com/google-amp/article/ok-microsoft-you-win-im-buying-a-windows-11-pc/ This is a good read too with links to checkers. https://www.zdnet.com/google-amp/article/will-your-pc-run-windows-11-even-microsoft-cant-say-for-sure/

The 06 official update is now available which includes this fix.

Can you post a sample file from there so we can take a look?

As mentioned before my fix only affects a very specific dropout code. If that isn't your issue it's a completely different problem

Yes a per fader history queue would be much more useful than a simple undo history that forces you to go from most recent to least recent. Yes mix recall currently requires you to make the decision to take a snapshot.

If anyone has Win 11 installed and running feel free to send us any compatibility issues you might encounter.

I think obsoleting laptops that are 4-5 years old is borderline ok. However with desktops its a different matter since many build them to be upgradeable. I typically spend a lot to buy a top of the line desktop just so that I can upgrade it. I expect it to last at least 7-8 years because of this. My 2015 8 core PC is still perfectly capable for what I use it for. The windows user base doesn't quite have the same disposable hardware mentality as the Mac base so its a tough sell from Microsoft.

You have to use MBR2GPT.exe to do the conversion. I spent more than half of Saturday dealing with switching to UEFI. I had 2 redundant recovery partitions created by buggy windows installs that I had to manually delete before I was able to use the MBR2GPT.EXE tool. I had to watch a bunch of YouTube tutorials before I figured out how to do that. Not for the faint of heart - I was afraid I would brick my system but it worked fine after I deleted the dead recovery partitions. Different tool to find out which one is in use and which is dead! If anyone needs to do this I can hunt down the videos I found that helped. The annoying thing is after all that work I got the CPU incompatibility message. It would have been far more useful if they listed all the problems at one time rather than piecemeal.

@Miki Fabian are you sure its the same problem? This is NOT a new issue with this release, but a preexisting mono bug that I fixed due to feedback from JL. What version of Cbb are you running when you say latest version and are you getting dropout code 12? Its a very specific issue so we need to be careful not to conflate it with other bugs. I've sent you a link to a build with a fix for the aforementioned issue. Report back if it fixes it.

There is no change to the actual synth port naming. It just wont put the prefixes into the track names when you insert synths.

@Josh Wolfer why not use mix recall which is designed specifically for this? And light years more powerful because not only can it recall fader moves for a subset of tracks, it can also recall envelopes and actual plugin settings. Arguably plugins are equally part of the mixing task these days. Mixing is a complex and very user workflow specific task. Someone might want to undo only fader moves on a single track but has moved a dozen other things after that. A simple undo stack is not useful for that. This is why we have per parameter undo memory (albeit only last value state). It could be extended to remember more than one value I suppose. However it seems like we already have all the tools there with mix recall. If anything we should enhance that feature rather than adding new less powerful features.

Reminder we are very close to releasing the final 06 update. If there are any blocking issues related to this release please report them ASAP. PS: As per requests the audio ports for friendly names no longer include the numeric prefix and I've also removed the prefix for inserted synth tracks. There are also a handful of additional bug fixes.

@buildanax can you please send the minidump file from the crash ASAP? There is info in the crash dialog that allows you to locate the dump file. It also shows whether the crash is in a plugin or the application.

Just because a couple of other DAW’s do it isn’t an argument for doing it. Tying fader movements (mixing operations), to the undo system is mixing and matching two completely different workflows. One is changing the data and the other is signal flow. They are two complete independent things and IMO should not be coupled. People do little changes to vol/pan interspersed with editing all the time. Having it in the same undo history will be very error prone and undersirable. If there was a mixer undo stack it would be completely discrete from the editing stack. Mix recall is a much more powerful system for managing fader state. And as pointed out we have a single per track level of undo for mixer state already. Also saving and restoring gain has little meaning when you have envelopes inthe project since they override the mixer when automation read is on. It would have to do it in offset mode which few people use anyway. Too many downsides to this which is why we don’t intend to do it.

Just starting a thread here to discuss Windows 11 compatibility. While we don't expect to have any issues with Cakewalk running on Win 11 getting your PC running it is a different story You may have read about the announcements that Win 11 only supports PC's with newer processors (Intel 8 gen and higher) and that it requires TPM 2.0 hardware support. In fact many of my PC's fail the upgrade test because I don't have TPM support and my CPU (though quite capable being an core Intel) is an earlier generation. Here is a new blog post from Microsoft where they appear to be potentially dialing back the requirements. I hope the requirements get relaxed because they seem a bit restrictive to only allow systems with TPM 2. I've seen some reports of soft and hard blocks for installation. Will be interesting to see how this evolves.