msmcleod

@John Noizz - thank's for the heads up & the dump file. We've identified the issue and a fix will be in the next release.

1. First you need to put the nanoKONTROL 2 in Mackie/SONAR mode by holding the set marker and rec buttons while connecting the USB cable from your computer. 2. Within Cakewalk, go to Preferences->MIDI->Devices and ensure the nanoKONTROL 2 's MIDI input/output are checked: 3. Go to Control Surfaces within preferences and add the nanoKONTROL as a Mackie Control surface: Note: Make sure it's "Mackie Control" - NOT Mackie Control XT or Mackie Control C4 4. Click OK on this dialog, and the main OK button on the preferences dialog to save everything. That's pretty much it for the nanoKONTROL 2, giving you control over transport, volume & pan. There's a few other shortcuts available using the Cycle button as a shift key:

Which specific model are you referring to? The setup for the nanoKONTROL is different to the nanoKONTROL 2 & nanoKONTROL Studio.

I don't think this is possible, not in a reliable way. Here's why: If you're using ASIO as your driver mode, you can only use one device at once (this is a restriction of ASIO within Windows, not a Cakewalk restriction). If your Octa-capture had an ADAT output, then you could plugin that in to the apollo's optical input, but the Octa-capture (AFAIK) has no such output. If you're using WDM you can use more than device, but you need to ensure the wordclock's are synchronised. The Octa-capture has an coax input, which could be used to slave to another device, however the apollo doesn't have a corresponding coax output. If you used WDM and ignored the fact that the wordclock's aren't in sync, you'll probably get timing issues - i.e. the tracks recorded through the Apollo won't line up with the tracks recorded through the Octa-capture. I guess you could manually adjust them afterwards, but that might prove tedious. The other issue with WDM is that the latency is going to be far worse than it is with ASIO. For your specific use case though, there is another way to do this which I used to do with my Alesis DM5: 1. Record your drums to a MIDI track. 2. Use the SPLIT NOTE TO TRACKS.cal to separate the drums to separate tracks. 3. Solo each track in turn, and record the audio from your Alesis Strike module through your Apollo (assuming that's your main interface). The other advantage of recording your performance as MIDI, is that you're not tied to using your Alesis sounds. You could route the MIDI to another drum VSTi such as Superior Drummer 3, Addictive Drums 2, Melda MDrummer etc.. (or use a combination of them for each drum sound). Another option would be to get something like a Behringer ADA8000 or ADA8200 to give you 8 new inputs to your Apollo. The mic pre's aren't the best, but the line-in's are (IMO) pretty much flawless. If you need better mic pre's you can obviously pay more and get something like a Focusrite OctoPre, or Audient ASP800, but if you're just using the Alesis Strike's line outs, then the ADA8000/ADA8200 will be fine.

This isn't static, this is a symptom of your buffer size being too small for the CPU load. You've not given any details about your PC configuration, e.g. CPU type / speed, but I suspect: (a) Your CPU is too slow ( or your power configuration isn't set to maximum performance ? ) and/or (b) The plugins you're using are too CPU intensive for recording. Its quite common for people to disable plugins during recording in order to reduce the buffer size/latency. Another thing you can try is freezing tracks to free up CPU load.

I went way further than that - cleaned the registry, unplugged everything (PCI cards, extra drives, everything USB except mouse & keyboard). I uninstalled pretty much all the drivers, including the hidden ones that weren't in use. I also uninstalled any software that had drivers - e.g. NI, Waves, iLok, OneDrive etc... The upgrade still failed. I think it was the 10th attempt at it this weekend... I'm pretty sure its either a motherboard BIOS issue, or a motherboard driver issue. If I can be bothered I might try a clean install, but I'd really rather not.

I seem to recall having problems with it before when transitioning from Waves v11.0.58 to v11.0.60. Re-installing it and doing a fresh scan in CbB solved it for me.

You're correct - it's the PC-2A that has to be in the internal directory.

ProChannel modules MUST be in the internal directory. Moving files around that aren't meant to be moved is bound to cause issues.

@Helene Kolpakova / @Keni - Maybe some state is being persisted between switching this setting on/off: Try this: 1. Go to File->Preferences->Initialization File 2. Set UseGlobalSnapForStaffView=1 3. Restart Cakewalk 4. Open the Staff View 5. Make sure Global Snap is set to "Snap To", and 1/32 6. Restart Cakewalk 7. Go to File->Preferences->Initialization File 8. Set UseGlobalSnapForStaffView=0 9. Restart Cakewalk

The setting is definitely read from Cakewalk.ini not Aud.ini. To change it go to Preferences->File->Initialization File All UseGlobalSnapForStaffView=0 does is completely bypass the previous changes to the Staff View snap with regard to the global snap. With this setting set to 0, the Staff View does not look at global snap at all.... in other words the staff view goes back to how it was in 2020.05.

Ok, a couple of things: 1. Disabling the handshake shouldn't be necessary with a genuine MCU Pro... but in saying that, if it's been working for you, it's probably not a big deal. 2. "Notes" are disabled in your Playback & Recording settings. All fader movements & button presses on the MCU are actually sent as Note On events. So I suspect that having this unchecked is filtering out the MCU messages. You may have to check Channel Aftertouch too.

Can you send a screenshot of the Mackie Control properties dialog (under the Utilities menu), and also your MIDI->Playback and Recording settings within Preferences?

I've tried to reproduce the problem here and I can't, so I'm leaning towards it either being an environmental or settings issue. The crash dump does however indicate that the crash is inside the BBCSO plugin. Since it's intermittent, it may be something else running on your PC that might be causing the issue. For example, are you sure there's no virus checker, backup software, or cloud sync app (OneDrive, Google Drive etc) looking at any of your VST or BBCSO content directories?

@NealClark - what build of Cakewalk are you running? The issue looks suspiciously like the "Add Track" issue we fixed in the 2020.08 Hotfix Sneak Preview.

It's actually used in two ways - the way described, but also you call it in (for example) the same way as you would set the mute for a track it should toggle the FX bypass.

Have you set the correct bank select method in your track?

A couple of observations: 1. When drawing controllers in the PRV, the number of controller events generated is related to your snap resolution. The higher the resolution, the more events will be generated, and this WILL slow things down due to the sheer number of events generated. Consider using a lower resolution (e.g. 1/64 or 1/32 notes or less) so that less events are generated. 2. Rather than drawing controller events, consider using the inline PRV + automation lanes for your controller events. This is a far more efficient method of both drawing and rendering controllers.

This button at the top of the VST window gives Keyboard control to the plugin instead of CbB: :

Apart from it's COM UUID, since the beginning of this year, there's no difference between Cakewalk's MackieControl and the MMcL MackieControl. The only reason to use the MMcL MackieControl DLL is if you want an additional Mackie compatible surface to work alongside (but independently) to existing surface using the Cakewalk MackieControl.

I think it's already there. Setting MIX_PARAM_FX to a value less than 0.5f should bypass the fx bin... Although within ControlSurface.idl, it claims to be a read-only parameter, there's definitely a handler for setting it within Cakewalk.

I've not got an x-touch to try it out on, but it should work as long as the x-touch isn't sending lots of extra messages as part of its emulation. I'm not sure whether the Cycle button or the Scrub button is best for the SHIFT key - you'll need to give it a try. How well it will work is down to the x-touch's emulation implementation. The PreSonus FaderPort 16 works pretty well, but it does get confused at times as to which mode it's in. [Edit] - Documentation can be found here: https://www.cakewalk.com/Documentation?product=Cakewalk&language=3&help=NewFeatures.31.html

I was going to suggest using a track template, but for some reason the pre/post setting isn't saved with the template. I'll raise this as a bug with the team. In the meantime, the quickest way to get around this is to use quick grouping to change all your tracks:

Only if you've defined mappings for your transport & faders.... if your controller is emulating a Mackie, you can probably map the transport, but faders probably won't work. The ONLY reason for installing the MMcL Mackie Control version would be to have a second (but independent) Mackie Controller alongside the Cakewalk Mackie Control. So in my studio, I use the Cakewalk Mackie Control for my MCU + XT + C4, and the MMcL Mackie Control for the nanoKontrol 2 stuck on the wall. This means when I change banks of tracks on the nanoKONTROL 2, my MCU +XT + C4 don't change with it. Of course if I change a fader for a track that they're BOTH looking at, then yes, both of them will change. The "special"mapping for the nanoKONTROL 2 was allowing the Cycle (loop on/off) button to be used as a shift key for the other functions. These aren't needed on the MCU as it has all the extra buttons, whereas the nanoKONTROL 2 is pretty sparse in that respect. ACT allows you to define mappings to parameters on the fly. You can't do this with the Mackie Control. With the Mackie Control, Synth/Plugin parameters are either assigned automatically (i.e. in order that the plugin reports them), or can be mapped within MackieControl.ini. I wrote the C4Mapper utility to edit MackieControl.ini for you. Also, when editing synths with the Mackie Control / C4, it works on the Synth Rack... not on the active track. To be honest though, unless you've got a Mackie Control compatible control surface with a display over each track, it's gonna be pretty hard to use as you'll be essentially driving blind unless you memorise where all the parameters are. I keep meaning to get around to writing a display emulator, but I never seem to have the time nowadays! The other thing with synths, is that there's so many parameters available that it makes editing almost impossible. Even with my C4, which has 32 knobs, it doesn't even cover the parameters for a single oscillator on most VSTi's. Effects are much less of an issue. I use my C4 all the time for EQ's and compressors, and I've set up mappings to make sure the knobs are in a similar position for each plugin so it's dead easy to jump to the right one. But with the nanoKONTROL 2..... I guess that leaves you with a choice... do you want to use the nanoKONTROL for transport / faders, or do you want to use it as an ACT controller for synths? If you want both, you might want to consider getting another nanoKONTROL 2 (or something similar from another manufacturer so the MIDI devices don't get confused) and use one for transport and the other for ACT.

The only way around this is to use something like ASIOLink : ASIOLink takes one ASIO device, plus a number of other WDM devices and presents it to your DAW as a single ASIO driver. It does actually work very well, but it's a complete PITA to set up! However... unless you can find a way of sync'ing the word-clocks between your devices, you may run into timing problems. From the device names, I'm guessing none of your interfaces have wordclock inputs/outputs.