msmcleod

Per-Output instrument tracks are essentially the same as Simple Instrument tracks with the exception that they have a MIDI channel assigned. So for a new per-output instrument track to be appended, it needs: 1. A spare audio output on the VSTi that isn't being used by any other instrument track 2. A midi channel on the VSTi that isn't being used by any other instrument track There's an important step though - you need to make sure that within Kontakt (or whatever VSTi you're using), you assign each instrument to its own unique audio output, and make sure it has a different channel for the input. Each VSTi does this differently, so you'll have to consult the documentation for each VSTi. Here's some examples: Kontakt: Omnisphere: TTS-1:

Looking at the code, it looks like it's always a sticky toast - there's no ini setting to change this for audio export.

What I tend to do is put the IR loader in an FX Chain and use the FX Chain input/output volume sliders to boost the signal.

Left click on the tempo scale and drag up (zoom in) or drag down (zoom out) in the same way as you would a clip. Double clicking on the tempo scale will force it to fit to the current extremes.

Yes - the synth properties dialog options are remembered for next time, so just uncheck "Enable MIDI Output" the next time you insert a synth. If you normally use the HUD add track dialog, you can still get to this dialog via the Synth Rack:

IIRC Sonar 8 came with Guitar Rig 3 LE, and Sonar X1 came with Guitar Rig 4 LE. Sonar 8.5 was an upgrade to Sonar 8 which came with the Project 5 FX suite and Session Drummer 3. I don't think there were any changes to Guitar Rig 3. So if you've got a non LE version of Guitar Rig 3, you've likely clicked on an upgrade button at some point, something else has installed or upgraded it for you, or it is actually the LE version, but it just doesn't say "LE" in the title. FWIW my version of Sonar 8 was boxed, but Sonar 8.5 was a download. This is reflected on the Cakewalk.com website - i.e. I can download Sonar 8.5, but not Sonar 8 (all I see is my serial number & activation code for it). I'll need to look it out, but I think the serial number for Guitar Rig 3 LE came in the Sonar 8 box. EDIT - just looked at my Sonar 8 box, and there isn't any serial number for GR3. Maybe it automatically registers after installing Sonar 8? Being so old, it probably needs to be run as admin to register properly. It may also be tied to Sonar 8, which means you may need Sonar 8 installed.

FWIW - that's the way I'd do it.

You don't need to choose between one instance or 16 instances. TTS 1 supports four separate stereo audio outputs, you can also use 4 instances of per-output instrument tracks giving you a separate audio out for each. But in answer to your question: One instance pros: less memory used, less likely to crash if inserted as 1st synth (this is a TTS-1 specific problem) One instance cons: the synth will be using one CPU core only (not a huge issue with TTS-1), any VST effects will be on everything 16 instances pros: separate audio outs, so each instrument can have it's own effect; better balancing over CPU cores, easy to replace a part with a new synth 16 instances cons: more memory used, may be more prone to crashing. A compromise would be to use 4 instances using per-output instrument tracks:

Unfortunately not, because the tracks are also selected... so hitting the delete key will delete the tracks. To delete notes, you need to range select them so the nodes have focus then hit delete. Alternatively you can right click on the envelope, and select "Delete Envelope". Neither of these methods are quick groupable though.

It is quick-groupable by holding down CTRL....

A damaged USB cable or dirty USB port can cause that. My USB hub has the sockets pointing upwards (so they collect dust over time), and I occasionally get this when my USB headset gets moved - it's just a sign the HUB sockets need a clean again.

When you open a project that was targeted for outputs that don't exist, you'll get a dialog asking you to remap the outputs. Just pick the new outputs and you should be able to continue. Sample rates are a different story. Most devices will automatically change their sample rate to that of the project, but if it does complain you can manually change the sample rate before re-opening the project.

A number of things could be causing this, such as: - "Use one file per clip" setting - The size of the audio file - The speed / fragmentation status of the disk. Creating separate file handles is a relatively expensive operation, which is why whenever possible Cakewalk packs multiple audio segments into a single file. This has it's downsides though, such as speed of editing. Even so, seeking through a large file can be relatively slow especially when it's fragmented. The fact that the project in question grows to 33Gb, but then ends up as 16GB would lead me to believe the size of the clip is huge - and the OP has said, they're 20 minutes long. That is a big audio file. I don't think I've ever gone above 12GB, and most of that was sample libraries, not internal audio. So I think in this case, trimming the clips down to size is the right call.

Earlier versions of SONAR rely on older versions of the Visual C++ Redistributable libraries. These older versions were bundled with the older Windows operating systems at the time, but newer versions of Windows have newer versions of the VC++ redists. The runtime bundled with CbB is an "all in one" VC++ redist, which includes all VC++ redists from 2015 onwards. However VC++ redists prior to 2015 will have to be installed manually. IIRC Sonar X1 was released in 2010, so it'll be using earlier redists. The ones you may need to install manually: 2013, 2012, 2010 and maybe 2008. I doubt if you'll need 2005, but you could install it as well if you have issues.

There is - the corners are "cut" at the bottom if there is audio that has been trimmed out:

Yes - Changes

Right click on the track, and choose "Replace Synth..." from the context menu.

Given that the arranger section seeking uses exactly the same mechanism as looping, I can't see having an inverted loop would help if you're having issues with the arranger.

You could apply trimming to the clips to shorten them to their new extents. Just right click on the clip and select "Apply Trimming". This command is selection based, so if you want to apply to more than one clip, just select the other clips before executing the command.

The only time I've seen this behaviour is when some other process is trying to access the files that Cakewalk is writing to during record. Anti-virus / Cloud Sync programs are the typical culprits. Make sure you've got your Cakewalk Projects directory and Global Audio folder excluded from any of these type of apps.

Sounds like you've installed an earlier version of Sonar after you installed Cakewalk by BandLab. Uninstalling/Re-installing Cakewalk should solve this. Doing this won't remove any of your settings.

Any bugs in subfolders would present themselves as UI issues - i.e. the track may appear in the wrong place, or be invisible. The folder ownership is purely a UI property, and is completely separate from the track's data model. The only bug I'm aware of that could cause corruption is to undoing a Ripple Delete with MIDI in lanes. It's hard one to reproduce, and we've yet to identify the cause.

I stand corrected... IIRC it was certainly an issue with earlier Roland hardware, so I probably just assumed it was the same with the TTS-1, which emulates the hardware.

The issues you describe definitely sound more like project corruption than bugs. If it's a bug, it will be for the most part repeatable every time. And for us to fix it we need a recipe to follow, because not only do we need to see what happens when a project is in a particular state, we also need to know how it got into that state in the first place - and that "how" is usually the bug. Before I joined the team, I was a beta tester, and I spent far more time trying to reproduce bugs from a fresh project than actually finding the bugs themselves. If the dev team can follow the steps and reproduce the issue, then there's a > 95% chance we'll be able to fix it. It's also much quicker to identify an issue in a project with one track, than debugging a project with 20 or more tracks in it. Project corruption is a different scenario though. Sometimes a project becomes corrupt due to bugs, but this is very rare - the code is littered with checks to ensure this doesn't happen, and also every user would be experiencing the same issue. So that leaves plugins... We all know that some plugins crash with a 0xc0000005 error - this is when a bug in the plugin tries to write to memory it doesn't have access to. However, the plugin is running in the same processor space as Cakewalk, so it has access to all of the memory Cakewalk is using. So what happens when it writes to the wrong part of memory, but this time it's memory it does have access to? Well, chances are that memory is your project, and it'll end up either corrupting the project or the state of other plugins. If you can, try to reproduce the issue in a fresh project with steps that are repeatable every time - then send that recipe to us.

You can also use the shelf tool: