msmcleod

As a general rule, MME is by far the worst performer out of all of the audio driver models. It's only really there for backwards compatibility with interfaces that have no other option. The drivers to use (in order of preference / performance ) are: ASIO WASPI Exclusive WASPI Shared WDM MME ASIO is generally the best choice, unless your interface hasn't got a native ASIO driver from the manufacturers. ASIO4ALL for example is not a real ASIO driver - it's just a wrapper around the WDM driver. So in most cases, WASAPI will be a better choice than ASIO4ALL. [Edit] - There are some exceptions: Realtek onboard devices have a really buggy ASIO driver, so WASAPI is best here. Some really high end audio interfaces have bad WDM/WASAPI support, so you really need to use their ASIO driver.

ACT only works one way - i.e. it only processes MIDI data from a device. It doesn't send any information back.

Just so you know, there's an issue with the saving of control surface presets in the 2020.08 release. The workaround is: After changing any presets etc a control surface dialog, go to Preferences->Control Surfaces and change one of the MIDI ports... then change it back. This will force a save of everything.

wow - there's a blast from the past. I got the book & DVD a LONG time ago. It's very good. One thing to note tho... if you didn't hate Thomas Dolby's "Blinded by Science" before watching the DVD, you certainly will afterwards....

I choose LibreOffice because it's the original OpenOffice devs working on it. Like most things that were bought up by Oracle, the devs left and started their own fork (like MySQL vs MariaDB). In saying that, OpenOffice is now part of the Apache foundation, so maybe things are different now. By UNIX, I guess you mean Linux.... there's a reason for the hoards of distributions. Linux is the base operating system for SO many devices, it's unreal. The point is, you can fork the main repo and take out or add what you want to suit your application (which in many cases may be a hardware device).

Some process has the file locked. The most common reason I've found for this is virus checkers/cloud sync programs (e.g. OneDrive). Make sure your Cakewalk project files (and your audio folders) are excluded from such programs. They will cause no end of issues if they lock files while Cakewalk is trying to access them.

Assuming any audio files associated with the .wrk file are in your Global Audio path, CbB should be able to open .wrk files without issue. If you're wanting to "upgrade" your .wrk files though, the best way to do this is: 1. Create a new project based on the "Basic" template 2. Drag the .wrk file into Cakewalk from the media browser. That way, you get a master/preview/metronome bus as well as all the pro channels enabled on the tracks.

I'm using Focusrite's as well, and I could take advantage of this too... the main reason I don't is that I tend to use ASIO at relatively low volumes. If I had YouTube running it would blast through my monitors at a crazy level.

I pretty much stick to ASIO, but have both my on-board realtek device and my audio interface going through a Mackie Big Knob passive which has an A/B switch. I never thought a glorified volume knob would be so useful, but it is!

I've had this issue twice. The first time was actually a bad RAM stick, but the second time was just some dirt or corrosion on the DRAM connectors. WD40 and a cloth sorted it out.

Go into Cakewalk Plugin Manager, and find the plugin within VST effects. Then click on Plugin Properties and make sure "Configure as synth" is checked: You'll need to come out of plugin manager completely and re-open it for it to pick up this change.

Just my personal take on this.... but I think its also worth noting that BandLab is a Singapore based company. It's very common for US companies (and a lot of UK/EU companies, although to a lesser extent) to insist that every product or project team is financially sustainable. My previous gig ( a US company) insisted that every product had to make at least $1M per developer working on it... so if it made less than that, either the team would be cut or the product canned. The main problem with this approach, is that some products are actually worth having even if they lose money as they act as advertisement, industry prestige, or an entry point to other more profitable products. In a similar vein, I'm sure many of us have worked for companies who have clients that use up so much of the company's resources, you wonder how they can make any money from them... but the point is, having that client attracts other more profitable ones. Those high profile but unprofitable products or clients may not make you money, but they do add value to the brand... which in turn makes money. BandLab has a family of brands comprising of software (offline & online), audio interfaces, guitar pedals, guitars, a huge music retail chain and some big names in publishing. The brands that make money pay for the ones that don't. Having a fully featured professional DAW such as Cakewalk as part of its portfolio not only adds value to the BandLab brand, it also provides a stepping stone for BandLab's online DAW users to move on to the next step. Personally I see it as no different from what a lot of us hobbyists or semi-pros do... I mean we may do paid music work, but I'll bet a lot of us spend more on gear than we earn from it. So how can we continue? Well, the day job subsidises it.

It looks like a bug in the handling ACT Control surface from within Cakewalk itself. I don't think this is due to the recent changes - it's an older issue, but it has a knock on effect on other control surfaces saving when the ACT Control surface is in your Control Surface list.

Interesting.... we did have an issue with it treating surfaces with a missing MIDI Out as disabled.... maybe that's the key. @azslow3 - can you confirm if the presets are saved if the controller has a MIDI out port set?

@azslow3 - the saving logic has now changed. The logic is now as follows: On startup, all of the control surfaces are loaded and a backup of the control surface persistence saved. For each control surface, If any of the MIDI ports are unavailable, this control surface is marked as disabled. On close, all of the persistence is saved to ctrlsurface.dat... however: - If the control surface is disabled, the backup of the persistence is used - If the control surface hasn't been altered, the backup of the persistence is used Maybe the last step is the issue... perhaps it should always call the real code if its not disabled.

Yup, I can 100% relate to that!

The Gain knob on MIDI tracks acts as a velocity trim. This isn't a design bug, it was a design decision. Whilst I don't disagree with your suggestion (which is a pretty sensible one to be honest), given that there's no MIDI equivalent of gain, your suggestion is no more valid a solution than what is currently there. In fact you could argue that since gain is applied at the beginning of the chain and volume at the end, velocity actually makes more sense than essentially having two controls over volume. Personally, I would argue that having gain control CC11 (expression) would be more suitable than either velocity or volume, but even then its behaviour is different depending on the instrument being controlled.... just as depending on the patch, velocity doesn't always make a change in timbre - or even in volume as you've pointed out!

Sometimes I really need to get the idea down before I forget it... other times, it makes sense for me to practise it until I get it right, especially when "feel" is a big thing for the part. But either way, I've found actually being able to hear it afterwards makes it WAY easier to play. I'll come back to it a week later (after doing nothing but listening) and play the whole thing without a glitch... very strange how the brain works!

Try uninstalling / re-installing BandLab assistant - and make sure your firewall isn't blocking it else it won't be able to download.

The BT suite doesn't come with Cakewalk - it came with SONAR. Updating Cakewalk would have had no effect on these plugins - the installation process doesn't touch existing plugins. Try doing a plugin scan from within Preferences.

I had a similar issue with downloading BandLab stems - I contacted the team in Singapore and they sorted it out. @Marcelo Arte - you can import blx files using File->Import->BandLab Project... but you need to download the stems first using BandLab Assistant.

Can you post a video of what you're doing? ScreenToGif is good for this: https://www.screentogif.com/

I'll put it to the team tomorrow... I'm pretty sure we've got something similar in the backlog though. In the meantime, checkout the transform tool on the PRV controller. Whilst it isn't quite exactly what you're looking for, it does allow you to alter the angle / shape of the controller data in a much easier way:

Right click on the widget area (where the slider that shows 64 is on your image above), and select "Remote Control". You can either manually select the input on the dialog, or click "Learn" and touch the ribbon. When you write enable the automation lane and start playing, it'll record the automation.

I can't seem to reproduce this - it's working fine for me with instrument tracks. Can you post steps on how to reproduce this? The "(volume)" envelope indicates either a MIDI volume envelope has ended up on an audio track, or an Audio volume envelope has ended up on the MIDI track... I can't get it into this state tho.