msmcleod

What filename tags are you using? If you're using the default preset, consider creating your own preset with a different set of filename tags.

No it won't. Certainly with pianos, MIDI should be sent out regardless of the polyphony of any in-built sounds of the keyboard you're playing it on.

The mic should be fine for recording vocals. If it's sounding muffled, there could be a few reasons: The obvious ones first... (ignore these if you've already used it on that PC successfully): 1. Make sure you're singing into the front of the mic, and not the back (not wanting to insult your intelligence here, but we all mistakes). A cardioid mic blocks sound from the sides well, but sounds coming from the back will sound almost as loud as the front, but muffled - which is why I mention it. 2. As it's USB powered, ensure you've got enough power going to it. Using a USB 3 socket, or a powered hub can help here. I had a Behringer C1 USB which sounded muffled due to insufficient USB power. Now the not so obvious: 3. Make sure the sample rate / bit depth match what the mic is. If it's locked to 16bit /48Khz, then make sure Cakewalk is set to that too. 4. Make sure any auto-gain or sound-enhancing effects in the Windows sound settings are turned off. This will interfere with the sound quality, if Windows sees your mic as it's default mic. Generally, USB mics are a bad idea in Windows for music for a number of reasons: 1. You can only use one ASIO driver at once in Windows, so you're basically forced to use WASAPI Shared if you're using another interface for audio output. 2. You're tied to the pre-amp built into the mic, which may be quite good, but you won't be able to plug it into a nice Neve 1073 clone if you had one. 3. XLR mics will last you decades. They work with, and will continue to work with just about everything with an XLR input. There's no guarantee that the USB drivers will work with Windows 1x in the future. Quality though, isn't really an issue - unless the mic's preamp is particularly bad. Just a note about the fact that it's 16 bit / 48Khz. The norm is to record at 24 bit nowadays, but you shouldn't really see a huge difference in quality with 16 bit. Your dynamic range will be less, but if you're singing well (i.e. with steady levels, and not all over the place), this should be fine. After all, 16 bit is fine for CD. If Cakewalk was mixing in 16 bit, then that really would reduce quality - and quite drastically... but it's not. Once the audio track is in Cakewalk, all mixing is done in 32 bit floating point (or 64 bit floating point if you have the 64 bit engine engaged). It stays as floating point right up until the point it reaches your audio interface, where only then will reduce the whole mix back to 16 bit stereo.

I searched by DAW and picked SONAR.

I'm still Seeing "SONAR Explained" (Artist, Professional, Platinum) and "SONAR Platinum Advanced" on Groove3 - both very good tutorials, and they're still 99% relevant. I watched these when I joined the beta test team (i.e. before I joined the dev team), and I can't recommend them enough. Up until this point my workflow was not much different from what I was using with Cakewalk Pro Audio 9!

Some changes were made a few releases back to extend the last take to the loop points/punch out points, to avoid splitting all of the lanes at the stop time. IIRC it only does this if the loop went around more than once though, otherwise it'd extend just a single take which isn't what you'd expect.

I wouldn't call this a feature request - it's more of a bug, or at least a bug of omission. It didn't take long to fix in any case - probably around a day at most. The delay in the next update is mostly out of the Cakewalk team's control. There are other things at play delaying the release.

Just a word of warning about Melodyne versions... Melodyne 5 does NOT work in Windows 7. Melodyne 4 does NOT work in Windows 11. Both Melodyne 4 & 5 work in Windows 10.

Hmm - those are VERY old .wrk files. Can you remember which version of CWPA you were using?

You should be able to copy the clips into new audio tracks though. Once you've dragged the .wrk file in, you should be able to open the .wrk file as a second project then copy/paste the tempos over.

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.