David Baay

One way or another, there has to be an overlap in order to do a cross-fade. In order to do that with Arrangements, Sonar would need to implement some non-visual setting where you specify that playback of each segment starts before the previous one ends and the resulting overlap is cross-faded. But I suspect that the way Arranger segments are currently processed would not easily allow this as it would require reading data from different parts of the timeline concurrently in real-time - or possibly buffering the different regions to RAM in advance - which doesn't currently happen in any other context. The process you described will work for the kind of 5-10ms cross-fades needed just to eliminate pops between discontinuous segments. But for longer transitions - as in movie scenes - you would need to actually render individual segments with significant added time before and after to allow overlapping their boundaries without moving them closer together which will foul up the timing of rhythmic material.

I suspected and just confirmed by checking the Ref. Guide that when controls are grouped, holding Ctrl temporarily overrides the grouping so you can alter one member independently - i.e. it becomes Quick Unrouping. So far as I know, quick-grouping of groups is simply not implemented. The simplest alternative would be to output each pair to an Aux track that outputs to the bus, use the grouped track volumes to contol the pairs and use quick-grouping on the Aux volumes as needed. If you're using matchng FX on each guitar pair, Aux tracks will also facilitate that and reduce the number of plugins you have to manage. Or don't create any permanent groups and, just use quick-grouping for everything, selecting what you want to control in each case.

Raising faders on the tracks the feed the bus will have the identical effect to raising Input Gain. Both will increase the level into the FX bin.

Not sure about the problem with quick-grouping of groups and not at my DAW to test, but you should be able to get the same result using Input Gain on the bus if only those six tracks are going to it.

If a plugin uses a lookahead buffer, enabling/disabling may require retarting playback for CW to re-calculate the delay compensation. In some cases this can happen automatically, but not always. This may depend on what plugin is involved, and where it is in the project. @Anders Madsen I should add that it may also depend on how you bypass it: via bypass/power button in the plugin's UI, by disabling only that plugin in an FX bin, or disabling the whole FX bin.

Double-click an empty area of the track header (i.e. where the double-ended arrow appears to drag it), and it will go to maximum height. Double-click again and it will return to its previous height.

You can't edit/audition events in a step sequencer clip in the PRV/Drum Pane, but adding events should create a separate MIDI clip and you should hear those. Can you hear newly added notes on playback? Might be best to share a copy of the project stripped down to that one track for troubleshooting.

How about the global FX Bypass in the Mix Module? Make sure that's not lit/enabled. 'E' is the default keybinding for it.

I would guess using a VSTi that echoes MIDI or installing virtual MIDI cable software with looback enabled. Otherwise the only way MIDI get's into another track is by a physical MIDI loop via having Out=Thru enabled on a keyboard controller or an interface that can loop MIDI internally, if not an actual cable between an OUT and an IN. That pretty much covers the possibiities other than some sort of project corruption. But given that CW isn't inherently capable of outputting MIDI to more than one port (much to the chagrin of many users), that seems unlikely.

Regarding the excess file length, you probalby have an automation node or something further out in the timeline that''s being interpreted as the 'End' in the absence of an End Marker or making an explicit selection to set the range as noted by Glenn. Regarding the flatline after 3:04, that's pretty odd. Maybe try setting a higher Bounce Buffer Size in the export dialog (I typically use 20ms). If all else fails, checking the Render in Real-Time box should do the trick if it's playing through normally.

Regardless of what approach is used to get bounces of each bus through the Master, separately, be aware that any compression, limiting or other dynamic FX on the Master are not going give the desired result because they depend on the input level of the summed signal and will behave differently (even to the point of doing nothing at all) when processing individual buses. The sum of compressed signals will never be the same as compressing the sum. Non-linear phase shifts in FX could also alter peak levels and cause other problems with the re-summed stems.

Cool. Glad to help. Regarding the audio engine problem; I can't really think of anything you could toggle on from the keyboard that would have shoot it in the foot like that. It may well be plugin-related. Any Izotope mastering plugins recently added to the project? They generally need a larger buffer to run smoothly. Beyond that, I would just check the usual suspects, starting with DPC latency: https://www.resplendence.com/latencymon

Possibly you have 'o' bound to Offset Mode, and inadvertenty changed gain or volume of the master bus while in Offset. It'as not a default binding but the default bindings of those keys would not otherwise alter the sound of a project. The two "o"s in 'Doctor' should have just toggled you in and back out of Offset Mode, but if you hit something in between, it could have changed the level.

I think I need an example situation to fully understand the use case, and how it's not currently covered.. Also, some other modifier will be needed as Alt-clicking a widget currently enables dragging it to re-order widgets.

Yes, I can confirm this is a longstanding issue. I believe I've reported it myself in the past.

Sorry, but that's not accurate. Solo override ensures that a track remains audible when anything else is soloed - exclusively or not - but does not cause the track to play solo when nothing else is soloed as a regular solo does. What it's doing is overriding the muting effect that soloing some other track(s) would normally have without causing any muting itself. I agree that using the same icon for both functions is a bit confusing, but it's not the functionality that needs to change, just the icon. There might still be a need for some additional soloing functionality but changing what Solo Override does is not the right approach. I use it for what it's designed to do currently and would not want it to change.

First, as a best practice you should set the Input of the new traack to the specific port and channel that you intend to record, not All Inputs. Then check the properties of whatever synth the re-recorded track is driving, and make sure it's not unintentionally echoing MIDI input to a virtual OUT.

That's right. Virtual MIDI port drivers working at the O/S level look just like hardware ports to Sonar, and you can apply an Instrument definition to them just like any hardware port. Only ports presented by plugins within the project cannot be used in this way.

So that sounds like a solution, though it doesn't explain the cause of the problem with the original project. Any time a project won't load normally but will load fully using Safe mode, I'm inclined to think some sort of 'race condition' is occuring on loading plugins or other content. Re-saving may have changed the order in which things load, eliminating the race condition. I'm guessing this is part of Noel's investigation.

Just for the record, my preferred approach is to Output the 'Master Bounce' track direct to the main hardware outs (i.e. in parallel with the Master bus) and group that track's Mute in opposition to the Master bus Mute. Then you can freely A/B between them with one click, and your live mix is ready for further work any time.

It looked to me like the PC he has is state-of-the-art enough to be quite servicable for at least a couple more years. Unless he's selling it to pay for the Mac...?

My expertise in this area is not great, either, but I've always been under the impression that dual-processor Xeon systems were not expecially great as DAW platforms primarily because they tend to run lower clock speeds, and overall DAW performance tends to benefit more from higher clock speeds than from having scads of cores. In any case, if one CPU is not being utilized at all, I would expect that's more a function of how the system and O/S are presenting them to the application.

You should be seeing its effect on the Master bus meter unles you have bus meters set Pre-fader...? FWIW, I typically use a 'Pre-Master' bus with no FX on it to sum all tracks and sub-buses and allow metering/managing the input to the Master.

If you're exporting only the Master, I think the only way the level of the file could be higher than the Master is if you've raised the level on the virtual hardware out bus at some point. If you don't see hardware outs in the Console view, drag the splitter at the far right to the left to reveal them.