David Baay

I have occasionally had MIDI I/O stop working after a crash because the driver is left in a bad state and the interface needs to be reset by power-cycling.

What I'm seeing is that during playback the slip boundary moves in increments much smaller than the snap setting, but noticeable. It appears to be right about 7 times my current 128-sample buffer = 896 samples = 18.67ms at 48kHz. Kind of a weird increment, but it may be variable, and/or I may have measured incorrectly. In my workflow I don't do enough of this kind of editing during playback to have noticed whether this is new behavor or not. I don't have CbB on this machine but can check Platinum 17.10. @msmcleod EDIT: I'm not seeing this in Platinum. I can't be sure it's not due to some difference in settings but seems unlikely.

Check if the Steinberg Generic Low Latency ASIO Driver has been installed at some point and uninstall it if present. This has historically interfered with CW even when not actually in use.

Right-click and drag a rectangle around nodes with the Smart or Select tool. With clips, anything you touch with the laso will become entirely selected, but in an automation lane only the nodes inside the lasso will be selected.

This should not be a problem. I'm thinking possibly you separately Locked Data on the MIDI clips (not part of Freezing) which would prevent cutting but not copying.

I can't repro that, and can't think what might cause it. Are you drag-selecting with the Smart or Select tool or lassoing with right- click, and does it make a difference? No, unfortunately there is no vertical level snapping option for automation nodes. The only workaround I can think of is to put nodes with all the needed values in a dummy track, and copy/paste them.

So I can sort of understand that it imight not be delivered with any factory presets, but you can save your own, right? Are you doing that? Sonar should save and restore the state of the synth regardless but it sounds like the T-Force is not responding correctly to some initialization message it's getting at startup. Try this: - Get a project working correctly by launching Sonar from scratch. - Archive the T-Force track and File > Save Copy As with '- Archived' added to the title. - Verify the current project is still playing as expected. - Browse to the copy of the project, open it, and un-Archive the track. - Does it play the expected patch?

This sounds familiar from another thread not too long ago, but I'm not immediately finding it. I'm thinking it had something to do with the default time range or source when executing a simple export from the Export module without going through the Advanced dialog.

Looks like a simple oversight in the development of the vector UI. I'm no expert but my impression is that very little carries over automagically; the devs have to re-implement almost everything, feature by feature.

On the contrary, giving your DAW software exclusive control of the audio interface driver is the first thing you should do to avoid potential audio performance issues, and that you absolutely must do to avoid actual issues. For years system tweakers have been advising to disable onboard audio while I've always recommended to keep it active and set it as the default device for Windows, browsers and other generic multimedia apps so they keep their mitts off the ASIO driver. And the DAW should always be using a dedicated audio interface with a native ASIO driver for anything other than casual listening or short-term situations where onboard audio with WASAPI is the only option. And while I don't think a lot of system tweaks are necessary, disabling CPU-throttling functions like SpeedStep and C-States in BIOS and setting Power Management to Best Performance are essential as well as checking for low and stable DPC (Deferred Procedure Call) latency, and if it doesn't pass muster, additionally disabling Bluetooth and WiFi in BIOS until they're proven to not be contributing. Beyond that I recommend not doing a lot of system tweaks unless some issue persists, and then trying them one at time to ensure they're effective - and not actually detrimental - as many can be. The same goes for Sonar Config File (AUD.INI) tweaks. Don't change anything from default without testing to see the effect over time and in different conditions. And don't automatically change anything as a matter of course on a new machine just because it worked well on a previous one.

Global Read button in the Mix Module disabled...?

Before doing this, it's critical to change the Follow Option to Auto Stretch so that Audiosnap won't base stretching on where the measure/beat transient markers are; it will just stretch the whole clip evenly. Bouncing renders any Audiosnap stretching to a new audio file that will have transients re-detected and now in different locations. Re-stretching a previousy stretched and rendered clip is going to compound stretching artifacts. If you decide later on that you want something different, it's highly preferable to start over with a previously saved copy of the project that's referencing the original un-stretched audio files.

If it were me, I would strip everything out of a copy of the project except the relevant track and buses, and if the issue persists, save that to a new location leaving un-referenced audio behind, Zip up that project folder, share it via One Drive (or other sharing site), and send Sasor a link. If for some reason stripping down the project fixes the issue, then you'll need to go over the routing of the rest of the project. I often find that the process of preparing a simplified project to demo a bug for Support reveals that I overlooked/misunderstood something. 🙄

yes, I meant to say real-time bounce to MP3 could be a problem. I haven't tested it for a long time, but I recall it has come up as an issue in the past, and I was able to easily reproduce at the time. But this was admittedly a looooong time ago, maybe even pre-X1 era, and on re-reading it seems the OP was fast-bouncing to MP3.

Anything real-time will always use the rea;-time ASIO buffer size, and bouncing will also, ubless overridden but a non-zero Bounce Buffer setting. I have run mine at 20 for years. If theory some rendeirng operaiton might be more efficient iwth larger buffers, but the main reason I raised it is that some plugins (especially soft synths) can misbehave when fast-bouncing with a very small buffer like 64 samples which I often use in real-time because I need low latency for input monitoring and my projects are mostly light enough that I can get away with it. Fast-bounce direct to MP3 is not recommended because the encoding generally can't keep up with the rendering. It shouldn't crash but you can get failures and/or bad audio. EDIT: Mis-interpreted what the export mode was, and meant to say real-time bounce to MP3 could be a problem.

Just to clarify the terminology, I read this as you've inserted multiple Sends on a track to different FX buses and the Sends are post-fader (the default). And the track's Output is assigned to the 'main vox' bus. Indeed in that case you should not see or hear any FX signal on the main vox bus when the source track's Volume is pulled down to -Inf. It shouldn't really matter, but I'm assuming the FX buses Output to the 'main vox' bus along with the Output of the track; is that right? First thing I would check is that what you're hearing is actually from those buses; do you see signal in their meters? Does any other track also send to those buses?

... or something 'reasonable' like 20-50ms. A very large offline render buffer (e.g. > 300ms) can precipitate issues like this.

Each pad can host from 2 to 10 different sounds with associated note numbers based on the underlying SFZ file(s) on which Session Drummer is based. The relationship between note numbers and sounds corresponds roughly to the layout of General MIDI drums which does not put the note numbers for like-sounds in strictly numeric order. If you right-click the kick and snare pads you'll see that the associated notes they cover (35-36 and 37-40, respectively) happen to be in order because that's how GM drums are laid out. But the Hi Hat pad covers notes 22, 26, 42, 44, 46 because GM distributes them that way, and all of those are going to go out the same audio out channel 3. Right-clicking other pads will show that the correspondence between note numbers and output channels is all over the place.

It's not. So long as the following conditions are met, everything should remain in sync as you make or revert additional changes: - The Timebase of all audio and MIDI clips remains the default Musical and they were in sync with each other and with the timeline/metronome to begin with. - Audiosnap Follow Project [Tempo] remains enabled on all audio clips in Auto Stretch mode and you have not not locked any clips. My guess would be that you enabled Audiosnap in some mode other than Auto Stretch before the first change or Audiosnap has somehow become disabled on one or more clips, possibly due to bouncing the clip(s) which will render any stretching permanent and disable Audiosnap. There are other things that could have gone wrong, but those would be the most probable. Ideally you will have kept an unstretched copy of the project from which you can start over, but even if you didn't, and you bounced some stretching, the original audio will still be available in the audio folder for you to manually recover the original state.

Sound on sound record mode.

Search 'ripple' in the Track View context in Keybindings rather than the default Global context.

AS mentioneded in your other thread, all versions of SONAR/CbB/Sonar that had an Inspecter should show the FX bins for all plugin types in both places. For tracks you just have to set the Track Control Manager at the top of the tracks pane to All, FX, or Custom with the FX Bins option checked, and the track sized to make room for it. Edit: I just saw the updates to your other thread. Yes, the exception would be 32-bit DX plugins for which there is no 64-bit wrapper. They would need to be replaced with VSTs or updated 64-bit DX versions.

All x64 versions of SONAR/CbB/Sonar should show 32-bit FX everywhere using the included BitBridge 'wrapper' to host them. If you don't see them in tracks, I would guess it's just that you don't have the track control manager at the top of the track pane set to display FX bins in tracks, and are only seeing them in the Inspector at the left. 'I' on your PC keyboard t oggle the Inspector open/closed.

My preference is to leave the metronome ouput assignment and bus as they are, and put a Send on the Metronome bus to an Aux track that I name 'Click'. I disable the Input Echo on the aux so it doesn't double the Metronome during recording, and you'll probably want to remove the send, change the Click track input to None and mute the track until you're ready to export. If the project has a fixed tempo and meter, you can save a little recording time by just punch-recording a single measure, converting to a Groove Clip with Ctrl+L, and rolling the clip it out to the end of the project.

The change from Layers to Take Lanes and the related addition of the Comp[osite] recording mode probably caused more consternation than any other changes. Most have embraced it, but some still see advantages to to the old layers implementation. Most of the available options for Take management relate to how Lanes are created and used are in Record options; right-click the Record button in the transport module and see the Take Behavior section at the bottom. You'll also want to read up on how the Comp tool works for editing takes and either use it, avoid it or disable it (right-click the Smart tool button in the Tools module).