Noel Borthwick

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.

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

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.

Well if you don't get a crash dialog what do you mean by crash? If you get a crash dialog it will list the dump file name. Post a screenshot or video of what you see when you save.

Moving the volume fader wont override automation that already exists in the track since the envelopes control the fader. What you are looking for is offset mode.

Do you have any mono only plugins in your project?

Are you using any Steinberg plugins that utilize syncrosoft copy protection? Do you have autosave enabled?

Right but how often does it happen? Once a day, once a week…

If you have a project where this is reproducible contact me and I can try and troubleshoot it with you using a beta build.

This is fixed for the final 06 release. See this thread.

Check out Voicemeeter it gives you an ASIO driver to send from Cakewalk