msmcleod

The issue is you're using WASAPI shared, which essentially goes through Window's sound. Use ASIO if you've got ASIO drivers for your device, otherwise try WASAPI Exclusive.

Technically they don't... NME Networks is not part of BandLab Technologies - they're a separate division, but both are owned by Caldecot Music Group. The same is true for the music hardware/instruments/retailers, which all come under Vista Musical Instruments, again owned by Caldecot.

If you've got an 18i20 then it works great via ADAT to the RME as an extra 8 pre-amps (or indeed an extra 8 analog outputs).

Do you have the outputs checked in Preferences? - i.e. they not only need to be listed, you also need to have them checked.

This has now been fixed.

The nodes must have been selected somehow for them to move as a group. The most likely cause is that you're unintentionally invoking a gesture that is causing them to be selected, or it could be a combination of config options that make this more likely. Can you post a video demonstrating this behaviour? Hopefully it'll be easy enough to narrow it down.

Is that really any different from a Track Envelope sending MIDI CC's to trigger articulations, or even sustain pedal events? FWIW - both Articulations and Track Envelopes can be converted into MIDI events in the clip, and back again - i.e. you can apply articulations to the track, so the key switches will end up in the clip, do any duplication or rolling out you need, then extract them out again later.

IIRC support for the MS GS Wavetable has been removed due to incompatibilities with Windows 11.

Ahh.. but drag and dropping file from it works absolutely fine 😉 I only use an iPhone because years ago I used a Windows Phone - great pocket PC, but absolutely useless as a phone ( e.g. having to get the stylus out, then select "Keypad" from the start menu just to get the keypad up during a call). A friend gave me his old iPhone 3GS which was so easy to use, I've been upgrading to the latest supported 2nd hand version since then. Maybe I'm just old, but honestly I think people expect too much these devices... I mean, sure, I do listen to audiobooks, do my banking on it, and take pictures of things I can't read so I can zoom in to read them... but for the most part I use it as a phone! But yeah, the whole having to use iTunes to get mp3's on to an iPhone is a bit of a PITA, but AFAIK it's the only way.

No that's not what's being said. The authorization server has been upgraded to support the upcoming Sonar/Next releases. This is incompatible with the old authorization server. When their authorization period runs out, the CbB 2022.11 release (and all releases of CbB before it) will try to connect to a now defunct authorization server, so the authorization will fail. CbB 2023.09 does work with the new authorization server. So: - If you're using CbB 2022.11 or earlier, it'll continue to work until the authorization period runs out. - At that point, you'll need to upgrade to CbB 2023.09. Of course, when Sonar is released you can always get that too.

If you're not comfortable creating an .ins file from scratch in a text editor, it's still fairly straightforward to create your own .ins file via the UI. Here's an example I did a while back for a Yamaha piano:

VST2 should definitely be receiving bank changes - it was one of the first things I fixed when I joined the dev team back in 2019. In order to get a complete patch list, I'd recommend using the Patch Browser in the Inspector, and setting the "List Patches From" to Roland GS:

I think this has just been missed from the release notes. The fix was done in the Sonar code in Feb, and applied to the CbB code back in April.

This isn't a beta version, it's an early access. If this bug wasn't found, it's likely this version would have been released as the final version. So far we're not aware of any other specific issues in this release, but we'll keep an eye out for any reports over the next couple of days. The back end servers have been upgraded to support the coming release of Sonar/Next. As as result, the previous versions of Cakewalk will no longer re-authorize once their authorization period has expired. This is what has delayed this release going out, and is also why there is no rollback. This bug has now been fixed, however with Monday being Labor Day in the US, it's unlikely we'll get a new update out before Tuesday. If you're affected by this bug: For the meantime, just make sure all of the strip types are checked in the console view's "Strips" menu. After doing this you may also have to launch the Track Manager from the console view and unhide any tracks.

wow, this one was a tricky one to track down! Ok - here's the cause: You've got MIDI strips unchecked in the console view, but also you've got "Keep track/console visibility states in sync" checked: So on project load, it's syncing the hidden tracks in the console view with the Track View. To fix this: 1. Ensure MIDI is checked 2. Open the track manager from the console view, and unhide the tracks (with the sync still on). There have been some bug fixes in this area, as sync wasn't working properly... but this looks like a regression. We'll look into it further.

FYI - this is the forum for Cakewalk by BandLab, not BandLab's mix editor. I'm not fully up to speed with BandLab's mix editor, but it seems to me you should be setting the time signature to 6/8 rather than 4/8.

Interesting - can you PM me a copy of your cwp file? I'll investigate further. In the meantime, check your workspace settings and see if setting it to "None" solves the issue.

Did you save the project after unhiding them? The hidden state is saved with the project.

FYI - this is also how you can easily add MIDI FX to an instrument track. When the MIDI tab is active, it's the MIDI track's FX bin that is shown in the inspector.

This is correct. Articulations are owned by the track, not by the clip. In this respect, they have much in common with Track Envelopes. To copy/paste they must either be explicitly selected in the PRV, or if you're dealing with whole clips you have "Select Track Articulations with Clips" checked in the Track View options menu.

@Jim Stamper - can you send a copy of your .cwp file to @Jonathan Sasor? We'll take a look at it.

I've just created a 10 min long piece out of copied 2 bar MIDI clips with lots of controllers, and it's almost definitely a combination of lots of controllers and lots of clips. You should see a huge decrease in sluggishness if you bounce all the separate clips into one clip. The best way to do this is to click the track number in the track view so that all clips on the track are selected, then right click on the clips and "Bounce to Clip(s)". The reason this has the biggest performance increase, is that the PRV effectively bounces all the clips into one clip in the background to view them all on the PRV. This step is essentially bypassed if there's only one clip on the track. To further reduce sluggishness: 1. Hide the PRV controller pane. 2. Within the PVR "Notes" menu, uncheck "Show Velocity" 3. Within the PRV "Controllers" menu, uncheck any controllers that are checked.

Are you sure they're actually being replaced? MIDI clips appear overlapped in the clips view rather than merged as a comp clip like audio. The best way to verify is to open the event view and see if the old events are still there or not.

AZController (or any of the other control surface DLL's) don't communicate with Cakewalk via MIDI, they use the Control Surface API which exposes a set of Cakewalk commands that can be invoked. The control surface may also be able to send a keypress to Cakewalk. This is how it works: Hardware Control Surface -> (MIDI) -> Control Surface DLL -> (API) -> Cakewalk Cakewalk -> (API) -> Control Surface DLL -> (MIDI) -> Hardware Control Surface In essence, any command that can be bound via a keypress should be available to the control surface DLL, although in reality the very latest commands may not be available, as not only does the API have to be updated, the control surface also has to be updated to make them available. I've not used AZController in a long time - @azslow3 is probably the best person to ask about it. His documentation should cover it though.

You shouldn't have to use sysex, and in fact I'd recommend NOT using it due to the size of the message payload. Most of the control surface DLL's take exclusive ownership of the MIDI ports assigned to them, so you can use any MIDI message you want without fear of it "leaking" into your recording. The Mackie Control surface is specifically designed for the Mackie MCU / MCU Pro, and the additional Mackie XT & C4 units. Not all control surfaces that emulate the MCU work as well as the original MCU, unless they have a specific SONAR/Cakewalk mode that has been specifically designed for use with SONAR/Cakewalk. The ACT Control Surface allows you to define your own messages, but does have its limitations and is one way (i.e. you can send messages to it from your control surface, but no information will be sent back to the control surface). @azslow3's AZController is by far the most flexible, offering pretty much unlimited control in both directions, with any MIDI message you can dream up... but at the cost of ease of setup. In saying that, there are plenty of presets for a range of different devices on his website: https://www.azslow.com/ If you've got C++ experience, you could always write your own surface using the Cakewalk Control Surface SDK. The source code to most of the control surfaces shipped with Cakewalk are there, so you can see how they're implemented, and use them as a basis for your own.