David Baay

I have a lot of pianos but not Ivory. The first order of business woul be to determine whether the problem is related to processing or to streaming samples from disk. What are you seeing in Sonar's Performance meter? Does it show high load across the board, spiking only one or a few cores with a lot Late Buffers or is the disk icon flashing red? Have you done any tweaks to Sonar's Config File (AUD.INI)? If so, you might try Resetting it to see if it runs better with the default setup.

Dragging with Clip Landmarks enabled (and musical resolution disabled) will do the trick if configured properly and is pretty much the only way to achieve this. I applaud Dougalex's creativity (my own brainstorming didn't hit on that), but it would take longer to make the splits and select the flatline clips for deletion than to just drag the clips together with Snap to Landmarks.

It could be that or that I fat-fingered Ctrl instead of Shift and didn't notice that I was drag-copying, as I can't reproduce it now. And, re-reading the OP's post, it does seem he might have been misunderstanding that Shift can constrain either dimension, depending on the initial direction of movement.

FWIW, one way to avoid this is to set the folder location for Project Templates to the Cakewalk Projects folder.

Yes, that's how it should work, but what I'm seeing is that I can drag it both vertically (e.g. from one track to another) and horizontally while holding shift (i.e. drop it at a new position in the new track. But there's some inconsistency. After allowing a two dimensional drag a couple times, it started working as expected Also when I re-enabled Snap aferwards rather than showing snap at a measure where I had left it, the resolution field was blank: Something fishy going on.

I can reproduce that Shift is not constraining horizontal clip movement as it should; I hadn't noticed because all the clips I've dragged recently were starting at 1:01:000 and/or snap being enabled at a measure was taking care of it.

What interface and audio driver mode, and are you using a conventional passive or powered mic or a USB mic? This sounds like some sort of electromagnetic crosstalk in the interface or mic power/preamp circuit.

I believe this is mainly a difference in terminology. Both Acid and Goove Clip files use a .WAV extension with the tempo, key and beat marker metadata encoded in the file header. So far as I know, Sonar fully supports the Acid format for .WAV files as well as .REX files.

Isn't that the point of using acidized files - that they'll be stretched and pitched to follow the project tempo and key? I don't compose with loops but I believe you can disable the default key-following behavior in the Groove Clip section of the Clip Properties tab in the Inspector.

That's because bounce to clip produces one contiguous clip with one hotspot to open the specified view. If the end of the clip is offscreen, Sonar conveniently displays it at the far right of the clips pane so you always have access to it without having to zoom or scroll.

I'd be surprised if you get much traction on this with the Bakers as support for virtual MIDI synths was deliberately deprecated but you can report it formally here: https://help.cakewalk.com/hc/en-us/requests/new The fact that the GS Wavetable is exposed in UWP mode is a fluke that I discovered incidentally.

It's not clear what you mean by "it completely ignores/bypasses any of my system MIDI settings to use Coolsoft VirtualMIDISynth as the playback device". If you can see Coolsoft in MIDI Devices when the mode is set to UWP (necessary to see virtual MIDI devices in Sonar), then you just need to assign the Outputs of the MIDI tracks to that device. If GS Wavetable is first in the list, the MIDI track outputs may be defaulting to that.

Maybe I misunderstood. I thought we were talking about comparing a real-time bounce to live output being input-monitored through Sonar. Those should sound the same. But if we're talking about comparing the bounce to direct monitoring of the analog output of the keyboard synth, that could easily sound different for various reasons.

Put the Compressor on the Master bus. When you're ready to bounce/export, set Buses as the source in the dialog, and choose the Master bus only. If the project has other buses, you can first Ctrl+Shift-Click the Master to clear all checkmarks and re-check the Master. Incidentally, if done correctly, the sound of your rendered mix will not differ at all from live playback (assuming both are mono) unless you're playing it back through a different app or hardware or in a different environment. If you're talking about it soundiing different through a mono amp in the performance venue than it does when listening to dual-mono monitoring in your studio, that's one thing, but the live and rendered digital signals should be identical.

I'm not aware of any such issue with X1. I have little doubt I could render the same project from X1 and the current Sonar, and they would null to perfect silence. If playback of an exported .WAV file sounds different in some other app through the same interface and monitoring system, either that app is coloring the sound or you're exporting something different from what's being sent to your interface on playback. If you're talking about a change in sound on different hardware in a differnet environment, anything is possible; your mix may not translate well. Bottom line: everything you're doing in Audacity can be done in X1 before export to achieve the same end result.

Several things have put me off that approach in recent years: - A regression bug that results in tempo changes not being entered exactly on beats. - Clip mapping not being restored when a project is saved/re-opened, so you have to get the mapping and extraction done all in one session. - Related to the above, a tendency for Sonar to crash when doing extended clip mapping work. - Even if everything goes smoothly, precise clip mapping can take as long as Set Measure/Beat at Now which has none of the other drawbacks.

Or (my preference), do it manually with Set Measure/Beat At Now - more flexible, more precise, and worth the time to get it exactly right.

Yes, but even if you don't use presets, the export setup is initially going to be based on the project template's settings and if you save a project after exporting with different settings, that's now the default for that project when no preset is selected. I tend to just rely on that.

I can confirm that Pow-r dithering options chosen in Preferences are not preserved when Sonar is restarted. This is not a per-project setting so should not be affected by template or project settings. That said, what others are getting at is that the setting in Preferences has been effectively superceded by the setting in the Export dialog which is a per-project setting and does follow the template used to create the project. So far as I can tell, the setting in Preferences is completely superfluous for new projects, but it might still be applicable to projects created in older versions of Sonar that don't have a value stored for the new export dialog.

Sonar's using ASIO while Windows will be using WASAPI; it's not uncommon for the different driver modes to present I/O ports differently. FWIW, I bought a used Ultralite mk3 a year or so ago. It was cosmetically in mint condition but I had to return it because the USB port (or its connection to the board) was mechanically flaky and would disconnect whenever the cable moved.

I am able to repro the lock-up in a simple project with one audio track and one Instrument track and in a new project from the Basic template. I use Go to Time frequently and it works as expected when executed directly with the G shortcut. When executed via the Assist feature, Sonar minimizes to the Taskbar and when brought back to the foreground will not respond to the mouse or keyboard, including trying to close it; it has to be killed in Task Manager. I checked other "Go to" functions and they worked okay so it's not affecting all transport functions as I thought it might be.

FWIW, the original response from Jonesey missed the point that bouncing the clip before stretching resolved the issue; it wasn't about online vs. offline rendering quality after stretching. The actual explanation is that stretching individual clips doesn't ensure the waveform at transitions between clips remains continuous; the phase and/or level at the ends of each clip can change indepndently, creating a discontinuity that produce a click/pop. In order for the stretching algorithm to produce a contiguous waveform at it has to be processing a single file. Bouncing before stretching renders crossfades and merges the multiple cropped files into a single file so they're all processed together rather than individually.

Perfectly safe and fairly common. Just move the entire Projects directory in one go with Sonar shut down. After restarting, go to Folder Locations in the File section of Preferences and change the path for Project Files. The greates drawback to this is that the Created/Modified dates of all the folders will change to the date and time you make the move. If that matters to you, there are 3rd-party file management tools that can preserve the timestamps Note that it's also possible to move whole program directories and things like Cakewalk Content and sample libraries to another drive and create a symblic link from the old location to the new one using mklink at an administrator command prompt: mklink /d "C:\Program Files\Cakewalk Projects" "D:\Program Files\Cakewalk Projects" Any reference made to the original location in the registry or by Cakewalk installers will automatically and transparently be referred to the new location with no performance impact. If the new drive is faster, performance can even be improved. I did this on my old desktop DAW when I installed an SSD in it and didn't want to bother migrating the whole C Drive and OS to it. I just individually moved projects, program directories, plugins, samples and the global Audio Data and PIcture Cache folders to it and created symbolic links as necessary. Works completely seamlessly.

John's okay; he just has early onset old codger.

Your dyslexia is getting the better of you; It's FXB: An FXP files stores a single Preset. FXB files store a Bank of presets.