[CLOSED] Cakewalk 2022.06 Early Access [Updated to Build 22]

[Jacques Boileau]

4 minutes ago, msmcleod said:

The Oxygen Pro itself needs to be in Cubase DAW mode, and AFAIK you should be using the second Pro 61 MIDI ports - i.e. MIDIIN2 (Oxygen 61 MKV) /  MIDIOUT2 (Oxygen 61 MKV).  The primary ports are used for the keyboard itself.

You can't use ACT at the same time as the Mackie Control, as the Mackie Control integration takes full control over the MIDI ports.

We'll look into why the Cubase mode isn't being recalled.
 

Dang, you are right, I used the wrong midi interface. It's actually MIDIIN3 that controls a DAW for the Oxygen Pro. Thanks, it works now. I'll play around with it and report back.

With AZ Controller I was able to use ACT alongside it by using both DAW mode and Preset mode on the Oxygen Pro. The Preset mode would control the plugins through ACT. Worked rather well actually, but with quite a bit of tweaking. 

[msmcleod]

5 minutes ago, Keni said:

Thanks again MS...

 

Work around appears to have been successful. A bit daunting with my limited language knowledge, but it appears to be working. This should prove a major relief as I do a lot of such work. I believe this is a much desired command.

 

A note though. Am I doing something wrong, something changed, or a bug?

In preferences|shortcuts, the key search isn't accepting a click on the ctrl/shift/alt buttons and will only search for the final key strike. I am also continuing to investigate the right pane (of this dialog) display for actual setup. As I mentioned earlier. The ctrl-M command shows bound to the create melodyne clip command, the right pane shows the command with no bindings at all.

CTRL / SHIFT / ALT are modifier keys, and are not considered keys in their own right.  The ctrl / shift / alt labels themselves aren't for clicking, and turn bold when you hold those keys.   In other words, to search for CTRL + M,  bring up the key search and press both CTRL + M.

CTRL + M is a factory binding, which shows up differently to a custom binding.  You can tell it's assigned, because it's in bold:



A user assigned key is displayed differently to make it more obvious:

[Keni]

12 minutes ago, msmcleod said:

CTRL / SHIFT / ALT are modifier keys, and are not considered keys in their own right.  The ctrl / shift / alt labels themselves aren't for clicking, and turn bold when you hold those keys.   In other words, to search for CTRL + M,  bring up the key search and press both CTRL + M.

CTRL + M is a factory binding, which shows up differently to a custom binding.  You can tell it's assigned, because it's in bold:



A user assigned key is displayed differently to make it more obvious:

Thanks. Good to learn more. I could have sworn I used to click on the ctrl then followed with the key, but my memory is degrading... I did manage to get it to respond, but combined with the right pane not displaying current selection/setting and even the binding descriptions being not always correct, I’m getting a bit confused. I just over-wrote the factory shiftM (set now time) with the new render command. I may eventually change that back, but I have never used the set command and constantly need the render. I can hardly wait to begin using it. Likely in the next few days as I’m currently working on lyrics/vocals for a new song!

[Jacques Boileau]

I played more with the Mackie control Cubase mode with my M-Audio Oxygen Pro. It works well. With very little effort the controls behave mostly as expected. For very little configuration, you can get a working control surface out of this keyboard controller. Even the loop button, which was not working before in my attempts with any combination of presets both in Cakewalk and in the Oxygen Pro, is now working. Here are a few limitations. These were there previously and are not new to this release. The only way I was able to circumvent them was to use AZ Controller. But it is much harder to setup.

• The master fader of the Oxygen will control only one side of the output fader. You can only choose one fader and they are separate left and right faders. But you can circumvent that by linking the faders in Cakewalk (padlock above the faders). A bit annoying but liveable.
• The pan do not behave as expected using the knobs on the Oxygen Pro. The range is half of what the pan in Cakewalk can do and the center of the knob does not correspond with the middle of the pan in Cakewalk. It seems kind of random, but I am sure there is a pattern, just haven't found it. The pan sometimes goes from -64% to +63%, sometimes -27% to +100%, etc.

All in all, a great improvement in getting an Oxygen Pro working with Cakewalk.

[msmcleod]

1 hour ago, Jacques Boileau said:

• The master fader of the Oxygen will control only one side of the output fader. You can only choose one fader and they are separate left and right faders. But you can circumvent that by linking the faders in Cakewalk (padlock above the faders). A bit annoying but liveable.

This can be configured in the Mackie Control Surface Dialog.  Set the master fader to control Bus #1 rather than Master #1.  This will mean it controls the first bus ( i.e. Cakewalk's Master bus) rather than the first output fader:


 

1 hour ago, Jacques Boileau said:

• The pan do not behave as expected using the knobs on the Oxygen Pro. The range is half of what the pan in Cakewalk can do and the center of the knob does not correspond with the middle of the pan in Cakewalk. It seems kind of random, but I am sure there is a pattern, just haven't found it. The pan sometimes goes from -64% to +63%, sometimes -27% to +100%, etc.

IIRC, the Oxygen Pro has two Mackie DAW Modes.  One is a high resolution version, the other a standard resolution.  Try using the standard one.

[Milton Sica]

9 hours ago, Lord Tim said:

Looking at the other thread you made, it's not clear if you've reported any crash reports to the Devs.

Us users can't help you because you're unwilling to tell us anything about your problems or your system. 

If this crashing was as bad and as widespread as you're saying, the forum would be up in arms about it, which it's not, so it's clearly something that's either constrained to or exposed by your environment.

It could well be a CbB bug that your environment is exposing. If you don't report it, unless someone at Bandlab is a clairvoyant, nobody will know if there's a problem at all, let alone trying to solve it.

We *all* benefit from people reporting bugs that get fixed. These EA builds especially are here for us to give it a good test before the public release - this is the time to bring up problems, document them and report them.

Hello. I know my answer in this thread at the moment is out of focus which is: THOSE USERS INTERESTED AND WILLING TO HELP DEVELOPERS IMPROVE THE FINAL VERSION is to download the EA version and be collaborative, polite and detailed in their feedback on the version.

Personally, for some versions I only participate in the EA by downloading, testing, etc. when one of the implementations, improvements or bug fixes focus on difficulties that I go through in the production version I use.

If not, I don't participate anymore, keeping my version in production and stable in full use.

In this way I think I help more than hinder. So I have avoided at times, including, for sure there are, some forum members who are not very kind in their approaches to what is brought by other users.

It's my vision. I leave the topic moderators free to delete this comment of mine if they consider it inappropriate and without focus on the topic.

However, I want to register my perception and it's just a perception, nothing quantitative or statistical, that, for some time now, I don't know exactly which EA, the participation of users in EA versions has been getting smaller and smaller.

Therefore, I believe it is up to the team to identify why this happens. If not, then let's move on.

I'll be waiting for the public version.

Hug to everyone.

[Lord Tim]

Well nobody *needs to* participate in the Early Access program at all, of course - it's optional for a good reason. But if people say they're having problems with new releases, this is a good way to get in early and test one before it goes public, and you know the Devs are actively here listening to reports and willing to help or look into it. And, if all else fails, you can always roll back.

[Promidi]

23 hours ago, Lord Tim said:

I don't think this is new to this EA. I've noticed that when you leave the Prefs window on the Keybinding page, it takes a while to open. If you change to any other category and press ok, it'll open instantly for me.

I have noticed this here as well for a while now in all CbB releases...I just have learned to live with it.  (It even happened in Sonar Platinum)

[Lord Tim]

12 minutes ago, Promidi said:

I have noticed this here as well for a while now in all CbB releases...I just have learned to live with it.  (It even happened in Sonar Platinum)

Yeah, I actually only noticed this recently myself when I was adjusting a few other things in Preferences, and then added a Keybinding, and exited when it was still on that page, and it took me a bit to work out why things were suddenly so laggy compared to usual.

I'm not entirely sure why it does this just for Keybindings but not for something like, say, Colour Options, but it might be something worth bringing up in another thread since it's not exclusive to this EA.

[Promidi]

20 minutes ago, Lord Tim said:

I'm not entirely sure why it does this just for Keybindings but not for something like, say, Colour Options, but it might be something worth bringing up in another thread since it's not exclusive to this EA.

I think it might be better to lodge an actual support ticket with Cakewalk support.  A screen recording (using something like OBS Studio not using phone) would be handy as well so the Bakers can actually see the issue in action - it should be fairly easy for them to reproduce.

https://help.cakewalk.com/hc/en-us/requests/new?ticket_form_id=360000025633

On a side note: As a test, I opened up Sonar Platinum and “zapped” all bindings - the delay in the Keybindings Preference dialogue box still happened.  So it's probably not from the database getting its knickers in a knot from years of adding custom keybindings (which I have done)

[Jacques Boileau]

4 hours ago, msmcleod said:

This can be configured in the Mackie Control Surface Dialog.  Set the master fader to control Bus #1 rather than Master #1.  This will mean it controls the first bus ( i.e. Cakewalk's Master bus) rather than the first output fader:


 

IIRC, the Oxygen Pro has two Mackie DAW Modes.  One is a high resolution version, the other a standard resolution.  Try using the standard one.

It depends on what is wanted. Using Bus will control the master fader and affect the level of any export done afterwards, unless there is something I am missing. Controlling the master reduces the level in the monitors and/or headphones but not what will be exported.

I looked but haven't found any setting high or standard resolution. But since I was able to make the pan work perfectly well using AZ Controller I won't research more. I have my pan knobs rotating from -100% to +100% and when the knob is centered it is always at 0 in Cakewalk.

I have done a few other things with AZ Controller that are not possible in what is offered in the Mackie Control Surface Dialog. If you are interested you can read what I have implemented here: Preset for the M-Audio Oxygen Pro 61 One other nice feature, apart from the pan working correctly, is mapping the Oxygen Pro selector knob to increment the movement of the WAI focus one track at a time, so I can more precisely focus the tracks I want to work with.  AZ Controller works well for me and I will continue using it. The new Mackie Cubase mode is a great improvement and will help less technical users I am sure.

My goal here was to help you test the new Mackie Cubase Mode on a piece of equipment you didn't have. It is a success on the Oxygen Pro. I hope my time spent doing this was helpful to you.

[Base 57]

On 5/26/2022 at 11:50 AM, Morten Saether said:

The Track view Options menu contains a new Expand Track Folder on Track Focus option, which automatically opens the focused track’s parent folder if it’s currently closed. This behavior may be desirable when using control surfaces or changing track focus via the Console view

I have found an unexpected behavior with this new feature. It works fine within a single screenset. But if you change to a screenset that has the Track Folder closed; the track focus will switch to the first track, unless it is also in a folder.

Otherwise, this EA is working well for me.

[Kyle Davis]

18 hours ago, Lord Tim said:

Us users can't help you because you're unwilling to tell us anything about your problems or your system. 

Here's the thing if i already did my thing in reporting the issue. I dont see the need to answer anyone here (NO DISRESPECT AT ALL.) My system specs (as stated in the previous post) has absolutely nothing to do with a crash. I honestly do see how that can help.

If it is "system related" then its between Cakewalk and Windows. Not system specs! 30years making music and never heard such a thing. You holding this DAW back by blaming "System hardware and specs" everytime it crash. 

Why doesnt Studio One, Reaper or Cubase crash with the same system specs everyone here keep crying about?

Edited May 29, 2022 by Kyle Davis

[Lord Tim]

1 hour ago, Kyle Davis said:

Here's the thing if i already did my thing in reporting the issue. I dont see the need to answer anyone here (NO DISRESPECT AT ALL.) My system specs (as stated in the previous post) has absolutely nothing to do with a crash. I honestly do see how that can help.

If it is "system related" then its between Cakewalk and Windows. Not system specs! 30years making music and never heard such a thing. You holding this DAW back by blaming "System hardware and specs" everytime it crash. 

Why doesnt Studio One, Reaper or Cubase crash with the same system specs everyone here keep crying about?

Nobody is blaming system specs. We are asking for it to see if there's anyone else with this configuration that may have run into the same problem. As I said, what you're experiencing may well be some change in Cakewalk that's a bug that's being exposed by something in your specific system configuration, be it a certain hardware device, a system or driver update... anything. By going "lalalala not my system" it's like calling up a car dealership and saying "my car was working great yesterday, what's wrong with it? No I won't tell you anything about it, and I won't bring it in, but it was working fine for years so it must be your fault. Fix it now."  It's a guessing game then.

Why don't those other bits of software crash with the same specs? We don't know. We don't know what drivers they're using. We don't know what's changed (and something has obviously changed) that's causing the crashes. Some other app may have updated a driver (eg: low latency audio driver) that could be interfering with whatever audio interface you have (we don't know what it is). You might have had a disk error on a crucial Cakewalk file. Something in your registry may have been overwritten with bad data. What everyone was telling you is that if you're getting horrific crashes everywhere with the last version, then why isn't the bulk of the user base here on the forum reporting the same? Logic says that your particular combination of hardware and software is making this happen on your system for whatever reason.

We're not holding back anything here, people are genuinely trying to help you help yourself by giving information. If it turns out to be Cakewalk then, sure, that's crappy news for the devs to find out there's a problem, but at the same time they now have a place to start looking to fix it for you, rather than you going "this crashes, you suck, but what about Cubase?" If you actually want help and the software to be fixed rather than just getting angry about it, take steps to make it happen.

Nobody at Cakewalk wants their app to crash for people, that's one of the main reasons for things like this EA program. It's another big set of eyes on something to see if there's things that both the devs and beta team missed because it's going out to a wider range of hardware and software configurations. If you really want to fix it, help the devs help you get it fixed.

But if this isn't good enough, roll back to the previous version. It's as simple as that. 

Edited May 29, 2022 by Lord Tim

[murat k.]

On 5/26/2022 at 7:50 PM, Morten Saether said:

Cakewalk will now install to ARM64 PCs running Windows 11 for ARM

This means now we are able to install Windows 11 on our ARM64 phones/tablets then run Cakewalk inside them. Fabolous!

[GreenLight]

9 hours ago, Promidi said:

On a side note: As a test, I opened up Sonar Platinum and “zapped” all bindings - the delay in the Keybindings Preference dialogue box still happened.  So it's probably not from the database getting its knickers in a knot from years of adding custom keybindings (which I have done)

It is interesting that the delay still happens even with no bindings. I haven't this checked with ProcMon, but maybe Cakewalk enumerates all potential keyboard shortcuts in the registry every time you open the dialog?

Edited May 29, 2022 by GreenLight

[Milton Sica]

When saving Project Model, the project is only being saved after the operation is commanded a second time.

I have no way to confirm if the first operation is still being performed in the background.

Steps used to replicate the problem with me:

1) Save as Project Template.
2) Close model.
3) Open new project using the previously saved template.

Note: The model is not saved on the first save operation. Just look at the MODIFICATION DATE list field.

[Olaf]

4 hours ago, Lord Tim said:

If it turns out to be Cakewalk then, sure, that's crappy news for the devs to find out there's a problem, but at the same time they now have a place to start looking to fix it for you, rather than you going "this crashes, you suck, but what about Cubase?" If you actually want help and the software to be fixed rather than just getting angry about it, take steps to make it happen.

There's a huge difference between saying "it would help us to know the system configuration, so we can get a lead on what needs to be fixed in Cakewalk" and saying "there's nothing in need to be fixed in Cakewalk, it's your system that's the problem (or plugins, etc)". The latter attitude is very discouraging. It shows people things won't get solved anyway, so why even bother? But if they're still here it means they're trying to help things to get better, and haven't given up yet.

[Lord Tim]

1 minute ago, Olaf said:

There's a huge difference between saying "it would help us to know the system configuration, so we can get a lead on what needs to be fixed in Cakewalk" and saying "there's nothing in need to be fixed in Cakewalk, it's your system that's the problem (or plugins, etc)". The latter attitude is very discouraging. It shows people things won't get solved anyway, so why even bother? But if they're still here it means they're trying to help things to get better, and haven't given up yet.

Absolutely agree!

In ALL software there's stuff that needs fixing, it's just the nature of software this complicated, and it's exacerbated by the millions of different combinations we have on the PC platform of hardware and third-party software. A lot of times it *is* some third-party software, or a hardware issue or even user error. But we shouldn't ever just assume that's the ONLY thing it could be - it's just a part of the puzzle. There's been so many bugs fixed by the devs here after they understood what else was influencing the behaviour, they they personally weren't seeing on their systems with their particular hardware and software configurations. Yes, it MAY BE the hardware, but the hardware might be actually fine... but it's showing up a problem in Cakewalk that needs fixing.

Keeping an open mind for where the fault lies and being ready to give information to help each other narrow down the issue is the key here. Passing the buck helps absolutely nobody.

[Olaf]

11 hours ago, Lord Tim said:

Keeping an open mind for where the fault lies and being ready to give information to help each other narrow down the issue is the key here. Passing the buck helps absolutely nobody.

Yes, I agree with you, it's a very complicated thing, and I'm amazed sometimes that DAWs even exist, let alone work. Personally I've been waiting for over 2 and a half years for certain things to get fixed, and I'm alright waiting a while longer, as long as it's clear things are heading in the right direction - which is, there's a common understanding that ultimately it's the DAW's responsibility to integrate and manage drivers and plugins, so that it behaves correctly regardless of the driver configuration, possibly faulty plugin instructions, etc. Like, for instance, it's alright to have a plugin stop responding, for conflicts, internal faults, etc., until things get solved by either developing team, but it's not alright to have that crash the DAW. And it's not clear how drivers or plugins could influence internal operations, like resizing audio clips, adapting them to tempo changes, having them jump in the timeline, having previously recorded clips play in the background while you're recording with monitoring activated, so on. That's the overall idea. Otherwise, we keep hoping for good things.

Edited May 29, 2022 by Olaf