David Baay

I'm still not able to reproduce a problem with high PDC and/or differing selection methods. The only anomaly I'm seeing is that the attenuation of the waveform previewed in the clip with the clip gain envelope is not accurate; the height of the waveform in the attenuated area is much lower than it should be everywhere. Right offhand I'd guess this is because a simple graphical scaling factor is being applied based on the visual height of the envelope rather than calculating the amplitude per the logarithmic dB scale. Whatever you have going on there seems to be project-specific.

As I recall there have been cases in the past where high PDC latency could cause sync errors with automation, but I don't know that any of that is persisting; I'll try to check. But it appears the second time you bounce with Ctrl+A and FX enabled, the 'Teaser' track was not soloed as it was previously. So the 'Entire Mix' is including other tracks and it's not clear what the waveform should look like.

I can't replicate this but there are too many unknowns in your routing and FX setup, and you're not showing the working case for comparison. The track is outputting to a bus named Voice and Music which presumably outputs to Master, and then you're exporting buses, importing the Master bus render, and routing the new track through the Master bus again . Both the metered and audible level of the whole export appears to be matching the reduced level of the clip rather than the raw level which suggests the clip automation is being applied but something else is going on that's masking the change in level - my first guess would be compression/limiting on one or both of the buses but it's hard to say without looking over the whole project. Try just bouncing the track directly to another track or soloing the track and exporting with Source = Tracks. And whether bouncing or exporting/importing, make sure the imported track is outputting direct to hardware main outs, bypassing the buses. In any case, I think the method of selection is less important than the Source for the export.

I'm not saying you shouldn't worry about it; I'm just saying it's not a bug. Any time you apply processing to a signal, especially anything not designed to have linear phase response, you need to watch the level of the output. Try a different EQ that's not linear phase, and you will likely get a similar result. A quick Google found this: https://www.soundonsound.com/sound-advice/q-why-does-using-high-pass-filter-make-things-seem-louder

Phase shifts caused by non-linear-phase EQing (or other processing) can cause peaks to change by small amounts. Put a loudness meter in the bin, or just switch the meter to RMS, and I doubt you will see an increase anywhere.

Do you have Punch Recording enabled? Normally an early note will be placed at 1:01:000 no matter how early it is, but if Punch is enabled, it might be dropped. I'd have to check. Historically, I've started almost everything at 1:01:000 unless there are 'pick-up notes before the first downbeat and never have an issue with lost notes. That said, I most often record without a click (or count-in) lately so would have to double-check that nothing has changed. EDIT: Did a quick test and confirmed a note played on the last beat of the count-in (i.e. a whole quarter note early) was recorded at 1:01:000 as expected. Enabling Punch muted the sound until the end of the count-in but did not affect recording the MIDI note. So I don't know offhand what could cause the reported behavior. Are you using USB MIDI from a controller or MIDI DIN on a standalone MIDI interface?

Please start a new thread for your specific issue, and clarify the symptoms of "screws it all up". The Event List view will usually be a better place to see timing/doubling issues. The Staff View is trying to fit MIDI timestamps to musical note values which may or may not give a good result , depending on the timing precision vs. the metronome and the display settings.

- What synth and patch? - Do you have Arranger sections defined? - What is your MIDI Prepare Using Buffer set to? Try something between 20 and 50 if outside that range. - Do you have a non-zero value set for BounceBufSizeMsec in Config File (AUD.INI)? If so, what is it? If not, try changing your ASIO buffer size (used by default for rendering when BounceBufSizeMsec=0).

Make sure your Playback and Record Timing Masters are I/O drivers on the same device. Try renaming AUD.INI and letting CW build a new one (I like to do this manually, but 'Reset Config to Defaults button in Preferences > Audio > Config File will do it for you). If successful, compare to the two files to find the root cause. I would also advise doing the opposite of this: I always recommend leaving onboard audio enabled and set as the default audio device for use by Windows, browsers and other generic multimedia apps so they don't try to grab your interface driver.

Not an unreasonable expectation, and works for other views as you pointed out. I was just pointing out that the issue in your example was due to a focus problem, not an issue with key bindings per se.

Mark is referring to the Transpose MFX, not Process > Transpose; the MFX can fit notes to a scale as the OP requested.

If you have Always Echo Current MIDI Track enabled n preferences, you can't permanently set track inputs to None. CW will automatically set a focused track to All Inputs - Omni because it can't 'Always Echo' nothing. The preferred approach is to set the track inputs to a hardware MIDI controller port so there will be nothing to echo when you're not actually performing on the controller. If you don't have a physical MIDI Input from a controller that's always available, you can set them to the Virtual Controller. If all else fails, disable Always Echo... and manually enable MIDI Input Echo only when needed. I typically take the belt an suspenders approach, and do both - assign specific input port (and channel) to every MIDI/Instrument track and disable Always Echo.

This is where you're going wrong. Clicking the tab in the Multidock does not focus the view. You have to click inside the view. You can verify this by trying to cursor down the list of events after clicking on the tab. The cursor will not move because the view isn't actually focused.

Vel+ is Velocity Offset. The value you set is added to all events in the track on playback up to a maximum of 127. To change the velocity of an individual event in the Drum Pane, hover near the top of the event until you see the velocity adjustment tool, then click and drag. Or show the Controller pane and drag the velocity tail up or down. P.S. If the Offset is already driving the net velocity to 127, raising the velocity of the event cannot add any velocity.

That can only heppen with a clip selected which would mean focus is still in the Track View.. Click in the open PRV, and then try it. If you haven't changed the Global assignment. Crtl+R will arm/disarm all tracks.

Renaming a clip is only applicable to the Track View. If focus is in another view (e.g. the PRV in the multidock), then the Global assignment will apply. If you don't want Ctrl+R to do anything outside the Track View, you should assign it to 'Do Nothing' in the Global context.

No sweat. I prefer to see/use italics for emphasis or maybe a few bold, lowercase words, and no more than one exclamation point. ;^)

Yes , I understand; no need to shout. Sjoens side-tracked the thread with mentions of Ref. Guide inaccuracy and using quick groupsing without selecting tracks so I took some time to address that as did you. My disagreement is with your use of 'SHOULD'. As menioned, regular Control Groups can work either way. Volume works the way you want Gain to work. But the way Gain works is not 'wrong' per se, it's just using the other convention. And to my mind it makes sense that Gains would maintain their levels relative to each other rather than relative to the arbitrary minimum of -18dB. If Gain went all the way to -INF like volume, it might make more sense for them to move relative to that point.

The thread I referenced was from September 2017. The last release of SONAR was 17.10, and I just confirmed it worked per the documentation - controls in all unselected tracks of the same type can be quick grouped by holding Ctrl when no tracks are selected. So it changed sometime after Bandlab picked it up. This was not a bug. It was intended behavior to make whole-project changes easy without having to select everything - like assigning all MIDI track outputs to the same mutlitimbral synth instance. But any time you have a function that can make a lot of changes with one simple gesture, you run the risk of users unintentionally messing up their projects, and this was one that they dcided to back out for that reason.

S#!+ happens . The team is tiny now; stuff is gonna get by once in a while. The Ref. Guide is highly reliable and useful in general.

If the sidechain input jack is configured as an INSERT (i.e. input/send signal between TS and output/return between RS of a TRS plug), then you might need to be using one side of a 'Y' Insert cable to take the mono output from your interface to the input side (TS) of the Insert jack. If you're using a mono cable with TS plugs at both ends or a stereo/balanced cable with TRS at both ends that might be the problem. Did that come up in your discussion with dbx?

Yes, but one of very few which suggests it's system-specific. In all my years I don't thinki I've ever had a custom binding spontaneously go missing. By any chance do you have 'Save changes for next session' unchecked?

Given how unusual a problem this is, I would guess something is going on with permisisons or antivirus on your system preventing the Windows registry from being modified or something. Nudge settings are also saved in the registry. Check if changes to Nudge values will persist. Also, maybe export your shortcut to a file and share it here to see if there might be some corruption that can be replicated on another machine. I have a 'test mule' installation on a laptop that I can freely experiment with.

To 'Select' a track means to left-click the track number to highlight it. Right-clicking a control and adding it to a group does is not technically 'Selecting' anything. Regarding what happens when you use Ctrl with no track selected. I do believe this behavior was deliberately eliminated and the documentation did not keep up. I'd have to search some old threads and release notes to find it. EDIT: Here's a thread from the old forum that discusses how dangerous it could be if you weren't aware of the feature. So it did work as documented at one time. This may have been the trigger for it going away: http://forum.cakewalk.com/Quick-Groups-Something-to-know-only-if-you-RTFM-m3651329.aspx

Meaning you want to have a track/bus in CW drive the siechain input of your compressor while it processes some other track/bus? I have not tried it but it should be pretty straightforward if you have the spare I/O channels availalable on your interface. Use an External Insert in the FX bin to apply the compressor to the relevant track/bus and route the sidechain signal to it via a Send on the other track/bus to another output. Are you encountering some specific issue?