David Baay

I know of it, but not details of that model. I have an H1n from a couple years ago that I have used only a handful of times to record acoustic piano via the mics. And I experimented using it as an audio interface for recording directly into Sonar just to see how that worked. It's been a while but I recall that it worked that way as well but not in a way that allowed input monitoring. Long-term you will want to look into getting a basic ASIO audio interface with built-in preamps and a mic or two to get the most our of Sonar and not be messing around with file transfers and syncing the project to audio recorded without a click. P.S. If you want to share the two original files from the H2n for download somewhere (or zip up the project folder with the two left-channel tracks already imported), I could set up the two mono tracks in a project with the stereoizer setup configured for you to experiment with.

Each track has an 'A' button to archive the track that basically tells Sonar not to process it when enabled. If you don't see them, set the Track Control Manager at the top of the track pane to 'All". It can be turned off an on any time the transport is not rolling with no permanent effect. What I'm thinking is that this will cause any initializaitonto be skipped for that track on opening the project which might help determine the cause of T-Force losing its patch settings.

The input to the H4n is probably stereo, but if you're going direct in with a cable from an electric guitar, that's going to be mono, and recorded on the left side of a stereo file. Sonar would import that as a stereo track by default, and the sound would be only in the left channel throughout the production unless you change the Interleave on the track to mono which would put it in the center, but you still woudn't be able to control the Pan position. The better way to handle this is to bounce the stereo track to Split Mono (see Tracks > Bounce to Track(s) options) and delete the flatline track from the right side. All mono tracks will continue to sound mono through a stereo bus unless processed by FX that specifically create a stereo image with differing left and right-channel information. Here is one technique for "stereoizing" a mono track that was recently re-surfaced: The alternative would be to record from the H4n's stereo mics near an amplifier(assuming both electric bass and guitar) in a room that isn't too lively. Or double-track the mono recordings, reproducing the timing and articulation as closely s possible (i.e. playing along with playback of the original tracks) and pan one left and one right. It might also be possilbe to just use the H4n as a pair of mics with a preamp to be recorded directly in a stereo track in Sonar via whatever you're using as an audio interface.

Copy and delete as Chaps suggested is one way. You can easily select all notes of a specific note number(s) to be deleted by clicking/dragging in the keyboard/note names pane at the left of the Piano Roll View. You can also do a partial selection of the MIDI clip by this method, and then Shift-drag from the source clip to a new MIDI/Instrument track in the track view. Shift ensures the timing is constrained.

Sounds like maybe a plugin on the Master bus has gone into demo mode due to the trial period or license expiring. Not sure what you mean by "freeze one card at a time".

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 seieng 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.