msmcleod

The best way to copy tracks from one project to another: 1. Open both projects in Cakewalk 2. In the source project, select the tracks you want to copy over and save them as a track template. 3. In the destination, insert the track template 4. In the source project, "copy special" the tracks, selecting everything in the options 5. In the destination, ensure the first track that was inserted with the template is active and the now time is at zero 6. Paste Special in the destination project. You may end up with some superfluous tracks at the end of the project (which you can just delete), but the rest of the tracks should be fine. I agree that much more could be done to improve inter-project copying, and being a Cakewalk user myself, I'd love to see it happen. However we're a small team, and it's a matter of juggling priorities.

By far the best way of dealing with .WRK files is to drag them into a new project rather than open them directly. If you use something like the "Basic" template, you get the benefit of a Master, Preview and Metronome bus set up for you already. I'm pretty sure this is how I converted all of my CWPA 7 / 9 files into SONAR cwp files. Opening .WRK files directly however left me with having to create all of these buses manually, a Pro-Channel that didn't work properly, and a bunch of other issues due to project options being deprecated over the years.

The Focusrite Scarlett 2i2 is the worlds most popular audio interface - and for good reason. It punches well above its weight for the price, and (AFAIK) is compatible with every DAW out there. The 2i2 is now on it's 3rd generation. I'm still using the 1st gen without issue. Going second hand is always an option if your budget doesn't permit buying new, and you can even get refurbished 1st & 2nd gen interfaces direct from Focusrite. I've got several Focusrite Scarlett models which I've had for a number of years now (18i20 in the studio, 18i8 for live recording, and the 6i6 and 2i2 in my office) - none of them have let me down. The preamps and quality is identical on all of the models, the only difference being the number of inputs/outputs.

Not wanting to come across as nit-picking with terminology, but the fly-out panel is just a short-cut to changing your selection without having to close the export dialog. This can be useful when creating multiple export tasks. In the context of the Export Audio dialog, "source" has a different meaning: "Source Category" - is where it should grab the audio from, i.e. is it grabbing it from the track outputs, the bus outputs, or the hardware outputs. The checked "sources" under the category are the sources within that category where the audio will export from. You'll get a separate audio file for each source that is checked. The selection however (which is what the fly-out panel allows you to change), is what is sent to those sources.

Thanks for pointing this one out - it makes total sense. It'll be available in the next update.

Both AudioSnap and Melodyne rely on transient detection to work out the tempo, so depending on the material, the results can vary. One feature that has been in Cakewalk since the pre-SONAR days is "Fit to Improvisation". To use it: 1. Create a new MIDI track, and arm it. 2. Start recording and tap quarter notes on your keyboard or a drum pad. Use the same note/pad throughout until the end of the song. 3. Select the MIDI clip you've just recorded, then choose "Fit to Improvisation" from the Process menu. A tempo map will be created based on your performance. Assuming you can tap in time, this is still in my opinion the most reliable way of creating a tempo map.

I didn't count latency as a performance issue per se, but I can see how it could be seen as such. The latency does differ between interfaces even though the buffer size could be the same. The bottom line though, is that it's up to the CPU to cook the buffers in time. Increasing the buffer size (and therefore the latency time) gives the CPU more time to cook the buffers. Cracks & pops are a symptom of the latency time being too low for the CPU to catch up with, but not enough to drop out.

Only to an certain extent - it totally depends on your signal path. For example, if I've got seven tracks all doing their own processing on their own threads, but they are then routed to a bus with a compressor on it, that compressor cannot process anything until all seven tracks have done their own processing first. It's like having 8 employees in a factory - 7 of them are producing widgets, and the 8th one puts them in a box at the end. The 7 employees are working in parallel, but the 8th employee can't box them until all of widgets are ready. Likewise, if you've got 4 effects in a track's effects bin they have to be processed serially, as the output of each one is fed to the input of the next. However, the FX bin of multiple track effects can be processed in parallel - i.e. the effects in track 1 can be processed at the same time as the effects in track 2 because they're not dependent on one another. The other thing to bear in mind with plugin load balancing, is that sometimes the task switching between threads can outweigh the benefit.

The simple answer is everything can affect performance, however for the most part CPU is by far the biggest driver - with CPU speed being the largest factor. While a greater number of cores can help, due to the serial nature of how plugins / audio mixing are processed, there is almost always going to be one thread/core blocking the rest for at least some of the time. So the faster the CPU, the quicker it can finish it's processing allowing the next lot of processing to be performed. Amount of RAM doesn't really make a huge amount of difference, unless you're dealing with large sample libraries. Of course, there is a minimum amount of RAM you will need to avoid unnecessary paging to hard-disk. The minimum recommended RAM is 16GB, which should be fine for general use. If you are using lots of sample based instruments, 32GB or more can help. 8GB is really not enough unless all you are doing is recording raw audio, and not using any plugins. Faster RAM will improve performance, but may or may not be noticeable depending on the project. Hard drive speed shouldn't be an issue unless you have a large audio track count, you use lots of sample based instruments, or you don't have enough RAM. An SSD is much faster than a standard hard drive. To give you an example: for me, Omnisphere used to take up to 45 seconds to load a patch from a HDD, which was reduced to less than 2 secs on an SSD. For the most part, the audio interface should have little if any affect on performance.

That sounds like you've put Cakewalk into CPU throttle mode, which restricts screen UI updates to once per second to give more CPU to the audio engine. The Pause button (usually next to Print Screen and Scroll Lock buttons) toggles this mode.

Both the VST2 & VST3 versions are working fine here - I'm running the latest version. Try updating it via Native Access, then do a rescan of plugins in Cakewalk.

I checked this yesterday - it's working perfectly for me. Obviously if you have "Keep track/console visibility states in sync" checked, there will be no difference between the "Track View" and "Console View" settings, but if that isn't checked you can have different sets of hidden tracks and the MCU correctly hides them according to the setting.

As long as the plugin ID is the same, Cakewalk will automatically use the updated version. Most plugin manufacturers keep the same plugin ID when they release new versions. Kontakt is a different matter however, and arguably for good reason. Unlike most plugins, Kontakt is more of a host for 3rd party libraries most of which rely on Kontakt's scripting language to facilitate their functionality. Take this hypothetical example: Say you have a library that used the scripting language in Kontakt 3. The scripting language doesn't do what the developer needs, so the library developer uses some workaround to get around the issue. However this workaround relies on a bug which is fixed in Kontakt 4... now, the library no longer works in Kontakt 4. Given that the vast majority of film/tv/media composers rely on Kontakt for their work, they can't be put in the position where a library they rely on no longer works when they upgrade to the latest Kontakt. Given there are literally 100's (if not 1000's) of 3rd party libraries, there is no way for Native Instruments to test them all with their latest release. So instead Native Instruments release the new Kontakt as a new plugin with a different plugin ID. This allows multiple versions of Kontakt to be installed - so if you've got a library that only works in a particular version of Kontakt, as long as you have that version installed it'll keep on working with that version.

IIRC, Overloud changed the way automated parameters work. This thread in the old forum covers the solution ( scroll down to comment #16) : forum.cakewalk.com/Solved-30th-Anniversary-CAX-Amp-Sim-FX-Chains-No-Longer-Work-with-TH3-349-m3791681.aspx

Are you using ASIO with the on-board audio device? If so, switch to WASAPI. I had exactly the same issue with the on-board Realtek device on my laptop - the ASIO drivers were rubbish and causing Cakewalk to constantly retry failed ASIO calls. In the longer term, I'd recommend considering buying a dedicated audio interface, especially if you're ever going to record audio.

I've heard Scan are pretty good - not that expensive (but obviously not as cheap as a home build), however they do build PC's specifically for DAWs: https://www.scan.co.uk/3xs/custom/daw-digital-audio-workstation-pcs I have used them in the past, but it was literally decades ago. IIRC their customer support was excellent.

Just a quick note regarding presets vs tasks: Presets - these specify the filename tags, general format settings and source category. They are meant to be global, so they don't contain any project specific information. Tasks - these are project specific, so in addition to everything the preset contains, they also contain the checked sources under source-category, the track/bus selection, the time range, and any encoder settings (e.g. MP3 settings / tags ). Additionally, although tasks are project specific, you can save them as part of a project template. Setting this up is slightly convoluted, as you need to create the tasks with audio clips present in the tracks, but then delete the audio clips when you save the template. But this can be useful if you do several common exports types for every project.

"Entire Mix" is the source category - which means, as you say, it's grabbing audio from the hardware outputs. This is totally separate from what you're actually sending to the entire mix.

It's not a bug. The export dialog is selection based. To export everything you either need to: 1. Select everything; or 2. Select nothing ( CTRL + SHIFT + A selects nothing ) The OP's screenshot shows "Track 10 Drums" selected, so none of the unselected tracks will be exported. Also, as Track 10 is a MIDI track, no audio will be exported unless it's corresponding audio track is also selected. The difference between selecting everything or selecting nothing is subtle: Selection: 1. A selection specifies both tracks and a start time/duration. If you save this as an export task, then the task won't pick up any new tracks or change in duration (assuming you've chosen Range = Selection). 2. When choosing Tracks or "Tracks Through Entire Mix", all tracks will be exported at the same length, i.e. the length of the selection. No selection: 1. No selection implies all tracks. If you create an export task, any new tracks will automatically be picked up. 2. No selection + Range = Entire Project will always export everything for the whole project duration 3. When choosing Tracks or "Tracks Through Entire Mix", each track will be exported at its own specific duration.

Sorry for chiming in so late in this discussion - last week was a busy one. I don't use any of the Roland TD modules, but I do use both the Alesis Nitro Mesh and DM5 with AD2. The Nitro is used for the standard kit pads, and I'm using the DM5 for extra cymbals (I modded some Remo practice pads to turn them into triggers). I've got both modules going to a separate input in my Miditech MIDIFace 8x8. The first three inputs/outputs are used by my Mackie MCU, XT and C4, with the Nitro Mesh on input port 4 and DM5 on input port 5. My main MIDI controller keyboard is connected to my Focusrite 18i20. Despite the heavy MIDI traffic, I've never experienced any glitches. If you want to use both the TD6 and the TD8, I'd recommend using a similar set up - i.e. have them connected to their own separate MIDI IN ports. Cakewalk will merge all of the inputs for you, but personally I prefer to set the MIDI filter to only listen on the two drum module ports and my main controller keyboard. This ensures that it never picks up anything from anywhere else. I had to build my own map within AD2 due to my strange hybrid setup, but mine is pretty close to GM. IIRC AD2 has drum maps set up for the Roland TD modules, but you can tweak the AD2 drum maps to adjust velocity curves as required.

Did you download the Focusrite ASIO drivers from their website? If not, do this. Windows will not automatically install the ASIO drivers, only the class compliant WDM/WASAPI drivers.

Why not just use articulation maps? Key switches are exactly what they were designed for. Also, there's no way for Cakewalk to know what keys match what instrument. Even if you based the keys/colours on the articulation map definitions, there's still no way for the the PRV to know which articulation map to pick, as 1. you could have many articulation maps in your project, and 2. you could have more than one articulation map defined for the same VSTi. If you've recorded key switches by playing them in real time, you can easily convert them to articulations by adding the articulation map to the project then right clicking on the articulation lane header and choosing "Extract Keyswitch Articulations". If you want to turn articulations back into notes, select "Apply Group 'xxxx' Articulations to Track" or "Apply All Articulations To Track" from the same context menu.

There is no difference in CPU usage either way.

This was changed a while back to get around a long standing (> 11 years old) Windows bug that has gotten worse since Windows 10 - if you go beyond around 1000 menu items, it starts removing items. This wasn't an issue in the past, because not only was the menu limit much larger (around 4000), most people didn't have that many plugins. So the workaround is to popup a brand new menu using a different UI framework.