msmcleod

I'm not seeing any issues here with scrub in the PRV. It's worth noting that AFAIK the MIDI scrub tool only works in the PRV - so using it on the track pane won't work (unless you switch to inline PRV), but it shouldn't freeze up. Do you have any custom mouse drivers installed? I've certainly had problems in the past with some custom mouse drivers - most recently with the Kensington software for my trackball. Uninstalling them and switching to the generic Microsoft driver fixed it for me.

Looks like this is a bug with Ripple delete and arranger tracks set to absolute time. We've got a fix - it'll be in the next release. In the meantime, adding a temporary section like you've suggested will work as a workaround.

Try holding down SHIFT when opening Cakewalk - this will force Cakewalk to re-initialize it's config files. It may be that they've been corrupted.

CbB doesn't support native bus folders, but you can get a similar result by clicking the folder to select all the tracks, then while holding down CTRL set the track output of one track to "New Aux Track". You can then rename the aux track to the name of the folder. You may also want to move the aux track to the top of the folder so it's easier to locate. You just need to remember to change the output of any new tracks you add to the folder to the folder's aux track.

IIRC Guitar Rig 4 LE was bundled with Sonar X1 Producer. You can't install that via Cakewalk Command Center, but you should be able to download the installers from your account at www.cakewalk.com .

The +/- buttons on the numpad work in the inspector key widget.

White noise is all frequencies at the same volume. Pink noise is all frequencies with the volumes of each frequency adjusted to "how we hear them" - i.e. we don't perceive loudness in each octave the same, so pink noise adjusts for this so it sounds like all frequencies at the same volume.

Not sure what is causing the crash, but the other behaviour sounds like you've got Ripple Edit on:

One of the things in the roadmap is "configuration presets", to allow you to easily swap between configurations. No ETA on this at present I'm afraid tho. In the meantime, something I've done for a number of years now (I've got 3 different audio device setups): 1. Set up your system for your first device 2. Copy TTSSeq.ini, Aud.ini, Cakewalk.ini & ctrlsurface.dat from %APPDATA%\Cakewalk\Cakewalk Core and put it in a "System A" backup directory. 3. Set up your system for your second device 4. Copy TTSSeq.ini, Aud.ini, Cakewalk.ini & ctrlsurface.dat from %APPDATA%\Cakewalk\Cakewalk Core and put it in a "System B" backup directory. Whenever you need to swap configurations, just copy those files from the relevant backup directory to %APPDATA%\Cakewalk\Cakewalk Core. I've got a batch file on my desktop for each configuration, so I just double click that before starting Cakewalk.

This isn't new behaviour. As a general rule, most commands apply to the current selection. Where quick grouping (i.e. holding CTRL) comes in, is when adjusting track parameters such as volume, setting colours, mute/solo etc.

@icu81b4 / @SketalDaz - in the next release, the "Freehand Smoothing" menu will be renamed to "Automation Smoothing" and will apply to both freehand drawing and recording automation. So: Smooth - will have the current behaviour, creating a smoothed approximation of the recorded automation. This works well for volume automation recording. As Drawn/Recorded (Jumps) - The recorded automation points are left exactly as they were recorded/drawn. As Drawn/Recorded (Linear) - The position/values of the recorded automation points are left exactly as they were recorded/drawn, but are joined together by a linear line. This is a compromise between Smooth and As Drawn/Recorded (Jumps). Use this if you're experiencing a stepping effect with "As Drawn/Recorded (Jumps)".

We ship basic chord triads as articulations with CbB as standard, but these are there for convenience in the PRV and fall way short of a chord track. A chord track, to my mind should: 1. Identify the chords within the existing audio/MIDI, allowing the user to correct them if necessary. 2. Allow the user to change chords within the chord track, and have this alter the chords within both the MIDI and audio - you should be able to exclude tracks from this process. 3. When changing chords, the chord picker should suggest alternative chords based on the current chord and key of the song. Alternative chords should be presented in order of which is most closely related to the existing chord, to those most distant.

It's the VST that causes the number of changes - not CbB per se. VST's are meant to wrap parameter changes in beginEdit/endEdit calls. That way, for example.. initializing a preset which alters 20 parameters is seen as only one change. Some VST's dont' do this, meaning it's seen as 20 changes. Automation can also trigger "changes" in the VST depending on the VST.

The smoothing is always applied when recording automation, however if using the freehand drawing tool afterwards, you can use the Freehand Smoothing option in the Clips View Options: Setting it to it to one of the "As Drawn" options should do what you want.

Typically you'd just add volume automation to the bus. You can either draw this in yourself, or typically what I'd do is record it via my control surface and ride the faders through the whole song:

It's worth mentioning that velocity is a property of the note event itself, not a CC (continuous controller). So changing a velocity envelope after the note has been initially sounded will have no affect whatsoever. As @Lord Tim mentioned, volume (CC #7) and expression (CC #11) can also be automated and are continuous controllers. Even so, depending on the VSTi, volume automation may not be picked up by notes that already playing. Expression usually does affect playing notes, assuming the VSTi supports it. If properly implemented, Expression should give the same effect as changing the velocity while the note is playing - i.e. you'll hear tonal differences as well as a volume difference. Volume however only affects the volume.

One of your synths has MIDI output enabled, whilst another is set to "Omni" for it's input (it'll appear as "None" if it's not the active track), e.g: Uncheck this: Disabling the MIDI output unless you need it is recommended, however it might also be worth setting the MIDI input of your synth tracks to "All External Inputs" rather than "None" or "Omni". If they actually require input from the output of another synth, then set the input to that only rather than "None" or "Omni".

It's always been this way. You can add your own controls to FX Chains (which in turn control one or more plugin parameters), and these controls can be automated. There's no ACT button, but there's a Learn button in the context menu which serves the same purpose. Alternatively, use "Extract FX Chain Plugins" to move the move them out of the FX Chain into the FX Bin. The ACT button will then return.

Make sure your mains output is set to 0db. If it's set to more than that, then that is why you're hearing a lower volume on export. In other words, Cakewalk is boosting the mains output by x amount, making it sound louder inside Cakewalk, but the actual level leaving the Master bus is quieter - and this is what you're hearing after export.

I suspect this is down to an interaction between "Split MIDI Notes" being enabled, and splitting a step-sequencer clip: When Split MIDI Notes is enabled, notes are split at the split point, and any controllers events are repeated at the split point. However, as step-sequencer clips also rely on the position of the notes/controllers being quantized to the step-sequencer grid, you may get unexpected results if you'd split the clip at a point that is different to the step-sequencer grid resolution. The simplest solution is to uncheck Split MIDI Notes. It does raise the question around splitting step-sequencer clips though. We could disable splitting step sequencer clips at any point other than the step resolution, however this might be a bit restrictive. On the other hand if we don't do this, it means that notes/controllers could be misrepresented in the step-sequencer view. To be honest, I'm not sure what the best course of action here is. I'll discuss with the team.

Thanks to @David Baay for a repro on this. The issue has been identified, and fixed for the next update.

Most features in Cakewalk have been developed with a particular workflow in mind. What I described was the intended workflow, not a workaround. As far as bug concerned, there are a lot of posts complaining about bugs which aren't bugs at all - it's just users complaining that the software doesn't do what they expect, either because they don't understand the feature, or it doesn't work the way they want it to work. If it is indeed a genuine bug, then the first step for the development team is to reproduce the bug. Once we've reproduced it we can then look into what is going on, why it is doing what it's doing, and hopefully be able to come up with a fix. But unless we can reproduce the bug in the first place, there's absolutely no way we can fix it. In this particular case, from what I can tell there is no bug with snap and stretch clips. It appears to be correctly applying a snap-offset to the snap. If the snap offset is being corrupted somehow, then that is the bug. However until we can get a list of steps to reproduce that, there's not a lot we can do.

Yes, use this setting: Checking this check box causes Cakewalk to save successive versions of a project with the date the project was saved in the file name. The most recent version has no date in the name. The number of versions to keep chooses how many versions to keep. When the maximum number of files is reached, the oldest file is deleted.

I can't reproduce the issue here. Stretched clips are snapping fine for me. @murat k. - I don't think there is a bug with snap and stretched clips. Looking at the linked post, it seems to be related to Snap Offset. If the snap offset is non-zero, then it sounds like the snap is functioning correctly - i.e. it's correctly applying the snap offset to the snapped position. The question is, what caused the Snap Offset to go to a non-zero value. @Diogo Tavares - if you can narrow down the steps that cause the snap offset to change, we can look into it and hopefully find a fix. If you keep the clip inspector open and keep an eye on the snap offset, hopefully you'll be able to narrow it down.

If you select your clip, then select "bounce to clip(s)", it will solve this issue. Another reason for doing this: By default, stretching a clip in the clips view will use the online method (e.g. Elastique efficient). This is very quick, but results in lower quality results. The idea is that you use the online method to get it to the correct stretch length, then use bounce to clip(s) to "commit" your results using the offline method (e.g. Elastique Pro) giving you much higher quality results. Once you've committed your stretch using bounce to clip(s), the clip is no longer seen as stretched - it's now a new non-stretched clip in its own right.