Noel Borthwick

I don’t see why you shouldn’t be able to mix live inputs rather than recording. (Not being able to hear your mix through headphones in a live room is a different physical problem of course) While track volume affects the post FX gain, Input gain will affect the pre FX gain. If I understand what you want, you should be able to set the input gain levels to mix all your live input levels to what you want. Alternatively if you want to mix post FX use track volume. @David Baay Input gain does affect live inputs since its applied immediately after the inputs and pre fix bin. Take a look at the signal flowchart.

Which version of Cakewalk are you running?

An aux track is a patch point connected to the track input. Therefore aux tracks need to have monitoring enabled just like normal audio tracks. Please refer to the signal flow chart. PS: Please translate to english before posting if you want replies since this forum is in english.

Look at the crash dialog does it say the plugin crashed? If so you should send the dump to u-he. We're catching more crashes in plugins now so if the plugin does something bad it will be reported. Prior to this the application could randomly be shut down in this scenario. About loading in another daw, please read the faq on diagnosing crashes. Please also send a link to the dump and we can follow up with them if necessary.

Dropouts on opening projects are not something to worry about. Well look into masking these in a future update.

It was only done this week so it's after the EA. I run at 2K (1440p) at 100% scaling and didn't notice a difference until I changed the scale to 150%. Since it's new we didn't enable this by default so any feedback is useful.

The difference is seen in text rendering when you are running with display scaling set to something higher than 100% in Windows. Take a screenshot before and after the change and you will see the text rendered better if you zoom in. Fonts are rendered much crisper. But with some plugin's not optimized you may see some perf issues.

What resolution are you running at and what are your display scaling settings in Windows?

Thanks for the report but this thread is to report issues SPECIFIC to the early access release not preexisting issues. Please post it in the main forum.

No you can only publish the currently loaded project.

This is most likely heap corruption or an unhandled exception in the plugin. In our next update we have enhanced error checking so hopefully it should catch this crash and report it via the crash dialog.

Thanks for the report. This is fixed for the final release

This is fixed for the final release

It would appear that you are logged into a different account in Cakewalk than your other bandlab account. You can log out and re-log in from the Help menu in Cakewalk.

I'm not seeing any difference in startup time irrespective of whether there is an internet connection. I can disable my network adapter and start the app and it takes the same time to load.

That is not a bug, what you are seeing is the divider for the bus pane. You can drag that to reveal the bus pane.

That is a picture not a video.

According to this shortcut list CTRL-D is a context specific shortcut for delete likely in windows explorer. It has no bearing on what individual applications do with that key. Its certainly not universal in other apps.

Which other users? This is the first I’ve heard of this issue Do you have delay compensated plugins in your project? Check if this happens in a MIDI only project with no audio tracks - just hardware MIDI. If you are using a virtual instrument which one are you triggering?

Thanks for the report. I’ll look into it.

@GreenLight the issue was quite simple. The browser caches up to 16 preview "voices" so that its fast to toggle between previewing different files. The problem was that when the bus was changed it wasn't resetting the bus for the cached voices.

I replied in the EA thread with the explanation as well.

Are you seeing VST2 plugins even when the equivalent VST3 plugin is available? Can you post a screenshot for that? This logic for finding compatible VST3 plugins is defined by the VST specification. If the plugin vendor follows the spec for coding the ID's of equivalent plugins only then do we know that it is an equivalent VST3/VST2 plugin. i.e this definitely works with Waves plugins. However many other vendors simply provide a different version of the plugin with a different ID. If this is the case Cakewalk has no way to know that its an equivalent plugin and it will be listed twice. Also if you open a project with the VST2 version it will not auto replace it with the VST3. Hope this clarifies the issue.

I have close to 1500 plugins and there is no issue. I think what you are trying to say is that you want the delay before the submenu auto opens to be shorter. This can be done but the reason for the delay in the first place is to allow quickly scrolling through a menu. If it tried to open every sub menu immediately it is very flickery and slower as well on systems that have a lot of plugins. We'll see if the delay can be reduced a little. @Ben Staton may have some tips on this.

@Mauricio Ramirez Thank you. Could you send a link to the minidump please.