David Baay

Altering audio hardware should not have any effect on MIDI or audio routing of simple instrument tracks. Split the instrument track and make sure the MIDI track ouput and audio track input assignments are still correct. Also make sure all MIDI track inputs are assigned the specific port and channel your controller is sending on, and not All Inputs-Omni. This will ensure that tracks don't unintentionally echo MIDI being generated by - or passed thru - other soft synths.

Hard to say exactly since your screenshot is showing the timeline or the snap setting. In general, Cakewalk does work like every other DAW on the planet in this respect.

Wow. I don't recall anything quite like that ever being reported previously. Is it repeatable or just happens at random/intermittently? Really sounds like some kind of memory corruption happening. What O/S? If you have a project that demos this with a repeatble recipe, I'd be interested in giving it a whirl on my system.

How old is your interface? Sounds a bit like symptoms of failing capacitors in the output section.

To see the 'Inline PRV' in tracks, set the Edit Filter that defaults to 'Clips' in the track header to 'Notes'. You can then adjust what is whon by the MIDI dropdown in the track view menu bar. Cakewalk can do partial quantizing of real-time recordings by percentage or groove quantizing to a selected or copied reference clip. There are also options to randomize hard-quantized notes using MIDI FX, but there is no really intelligent 'humanizing' funciton built-in. It's not clear what's happening that's requiring you to restart Cakewalk or your PC. What are the symptoms, what audio interface and driver mode (ASIO, WDM, WASAPI) are you using?

As I said, I assume that by 'current channel' you mean the output channel assigned to the track. If you have a separate ouput channel assigned to each track and only put parts for one instrument on each track, that output channel assignment will take care of re-channelizing everything as a needed. If you're not using forced output channels, you should. In the case of non-multi-timbral instruments, channel doesn't matter at all; the dedicated virtual MIDI port presented by that instrument ensures that no other synths see that data, and most single-instrument soft synths will respond to MIDI on any channel.

Someone else mentioned this in another thread, but I checked the current release against the last release of SONAR Platinum, and also X2, and did not see any difference on two different machines (one ASIO, and one WASAPI). As I mentioned in that thread, the Now cursor has always been a bit jittery at higher tempos and zoom levels for me. It could certainly prettier at higher zooem levels. That said, I suppose it's possible they're all using some shared code, and all are more jittery than before, but I haven't noticed a change. At what tempo and zoom level (measures in view) are you noticing it's worse.

I think Mark will confirm that Cakewalk has no mechanism to force a buffer size change. Though it might not be the whole story behind the issues you've encountered, any change in the buffer size wasn't directly due to the update.

That's a high buffer setting. Is the project pushing your CPU that hard?

If it's working with standalone synths, drivers should not be a problem. First of all, if you're using WASAPI driver mode, change your default rate for new projects to 48kHz; Noel posted earlier there's a known issue with WASAPI at 44.1kHz. EDIT: Looks like the hotfix is already out: If still a problem, let us know which of the following steps doesn't give the expected result: - Make sure both the MIDI and Audio devices are enabled in Preferences. - Insert TTS-1 as separate MIDI and First Audio Output tracks. - Set the input of the MIDI track to the keyboard. - Enable Input Echo on the MIDI track. - Play the keyboard and look for MIDI output activity in the MIDI track meter. - If you see activity but don't hear anything, open the TTS-1 UI, and click one of the audition buttons at the bottom of a channel strip. - If you still don't hear anything, open the Console view, drag the pane dividers to the left so you can see the hardware out channel strip(s), click and audition button again, and look for activity in that output meter. - If you have activity there, and still don't hear anything, and you're sure your monitoring sytem is active, something's going on with availability of your audio drivers to Cakewalk.

So why not just write everything as channel 1 in all tracks in the first place and let the forced output channel take care of the rechannelization as I suggested?

Not sure what you mean by this. If you make only one track at a time editable in the PRV tracks pane, you can't see or write controllers on another track. Those two statements are contradictory, and the first one is correct in my view. If you write channel 1 controller events to the channel 4 track, they'll be forced to that channel on playback along with note events, and if you save as a MIDI file, Cakewalk will re-write all the events on the track to channel 4. This happens with Save As .MID regardless of whether rechannelMIDI is enabled in Cakewalk.ini. Knowing you have a lot of experience, I think I must be missing something about your workflow.

Processing by selecting something in the Process menu, or by bouncing to clips/tracks? Need a more detailed description of the steps.

Save the desired layout as a Screenset or Lens. A screenset will be specific to the project in which it's created. Lenses affect all projects. Then, rather than closing the PRV, just change screensets/lenses.

You can copy (everything or selectively) the following: The Cakewalk AppData directory: C:\Users\<username>\AppData\Roaming\Cakewalk\Cakewalk Core (including an export of your current keybindings as a .kbn file) The Cakewalk Content directory (mine is in a non-default location, not sure what the default is)

The selection markers allow you to easily change a selection by dragging the marker, and the new pointer tools allow you to select the desired marker when two or more (loop, punch, selection) markers are on top of each other.

Just curious... do you use a touchscreen? I almost never use the UI transport controls with a mouse; the keyboard shortcuts are so much more convenient.

I'm guessing you mean the current forced output channel of the track. If the track has a forced output channel assigned, the channel embedded in the events doesn't matter. In the age of soft synths, most users write/record everything as channel 1, and depend on independent ports and/or forced output channels on tracks to route events to the proper synth and channel.

I have a problem with the VST3 version of AAS Chromophone 2 causing a crash that the VST2 does not. Others don't experience this, (including AAS themselves, apparently). If re-installing/re-scanning doesn't solve the problem, you might try replacing the VST2 with the VST3 after its loaded, which works with Chromophone.

A 64-bit plugin can address more memory, though I can't imagine an FX plugin needing more than the 4GB supported by 32-bit addressing. And I would challenge you to hear the difference between 32-bit and 64-bit audio processing, especially in a plugin that is probably already introducing subtle distortions in the signal by the nature of its DSP algorithms. I'm not a devleoper, but I believe making plugins use 64-bit addressing is primarily just so that ithey can run in a 64-bit environment without address translation a.k.a. 'bridging'.

That would be audio bit 'depth' as opposed to data bus 'width'. I don't know for sure whether CA-2A was included in the IP package that Bandlab bought; maybe Steve does. But it doesn't appear Cakewalk are putting any energy into plugin development right now, and the return on investment of updating CA-2A to use a 64-bit signal path would likely not be very attractive.

You're confusing x64 memory addressing and data buses with 64-bit audio processing. If you're running x64 Cakewalk on an x64 operating system, the matching version of CA-2A will using 64-bit addressing and data bus, but apparently it does not support 64-bit audio processing. Some other high-end plugins don't either. You'd have to ask the developers why not.

Yeah, that works. I think it will be a little easier to keep track of the process - and know at a glance what's doing on after the fact - if you put the different articulation in different lanes.

No, that has never been implemented. The only visual guide is that 6dB intervals are marked in the track scale, and each 6dB change in the Gain line will halve/double the amplitude. Ultimately, you have to use your ears.

64-bit signal path shows two ticks close together for each channel of the stereo path: