msmcleod

Can you show more of the dialog? In particular the "What to Export" section.

Are you sure you don't mean Sound on Sound? - Overwrite mode literally overwrites what you've previously recorded. - Sound-on-Sound allows you to build up a track by recording several takes, whilst hearing the previous ones - Comping records several takes while muting the previous takes, so you can quick-comp the takes choosing the best bits afterwards.

Actually, it is setting the Time+ to a negative value... but the key difference is to also be able to specify this in milliseconds, rather than the current implementation which is in musical ticks only. A lot of orchestral libraries require a negative millisecond delay. This is to account for things like the bow touching the string on a violin before it actually plays the note - i.e. you get the note to start early so you hear the "bow" effect, but the actual musical sound starts playing on grid. A delay in musical ticks is fine if you've got a single tempo in your project (you just workout how many milliseconds a tick is for that tempo, and enter that tick value), but if you've got tempo changes, then the actual length in milliseconds of each musical tick will change with every tempo change. Also, I believe the current implementation allows you to enter negative time, but doesn't actually respect it (it clamps it to zero). The workaround in CbB is complicated. Essentially, you have to add a positive delay for all other tracks, equal to the tick equivalent for the largest millisecond delay. For each tempo change, you're going to need a complete new set of tracks with a different delay. As to why it's not here yet - simple answer, is it's really complicated. The MIDI engine schedules groups of notes ahead of time in time windows (based on musical ticks). A negative delay requires scheduling notes early, meaning they might need to be added in an earlier time window, with the reverse being true for positive delays. Get it wrong, and you get doubled notes or missed notes (we suffered both issues in the early implementations of the negative articulation delay). Not only that, each and every MIDI event needs to be time adjusted, converting the millisecond value to its new tick value - this requires a lookup of the tempo map for every event. Add looping / user seeking in the timeline, and it gets complicated really fast.

If you uncheck "Always Echo Current MIDI Track" in Preferences->MIDI->Playback and Recording, it'll stay set to None.

When this happens, I just record a cover song... not only does it help to get back into the swing of things, it also gets your muscle memory re-engaged without having the pressure of being creative. There's nothing more frustrating than not being able to "drive" your DAW without having to to think about it.

Glad you sorted the issue. What plugin manufacturers should be doing if possible, is ensuring their automation parameters match between VST2/VST3 - I guess this isn't the case for some of your plugins, which is likely the reason it didn't work.

My bet is you're using a Workspace that is hiding surround. Try setting your Workspace to "None".

I think it's more likely to be a plugin version issue than a Cakewalk version issue, especially if the plugin went through several upgrades from an earlier version on your previous machine.

FWIW, you do have the following options: - Use "All External Inputs", which will exclude any soft synths. This option appears as soon as a soft synth is inserted. - Use an input preset

Back in the hardware days, you had three flavours of MIDI ports: 1. MIDI In, MIDI Out, MIDI Thru - where Thru was an exact copy of what came from In, and Out was whatever the device generated 2. MIDI In, MIDI Out - MIDI Out only had what the device generated 3. MIDI In, MIDI Out/Thru - here, the MIDI Out had both what came from MIDI In and whatever the device generated. There is no MIDI Thru in software synths, so it's up to the plugin vendors to decide what their MIDI Out does - i.e. some behave like (2) above, and some behave like (3). If you have one that behaves like (3), then the synth will essentially repeat whatever it received from the MIDI track. If you have another track that is set to "All MIDI Inputs", then it'll receive MIDI from that soft synth. This isn't a bug - it's just how it behaves. You just need to be aware of your MIDI routing.

@Kurre is correct - the option wasn't available in CbB. CbB doesn't support different DPI settings - instead it tells Windows that it's not DPI aware, and Windows automatically scales the UI accordingly. For the most part it does a pretty good job, but can lead to fonts/icons being slightly blurred as part of the scaling. Sonar on the other hand is DPI aware (a mammoth development task), which is why those options are available. Dealing with Plugins, especially those that are DPI aware and/or support scaling is tricky, as depending on how the plugin is doing it's scaling, Sonar's DPI adjustments can end up fighting with the Plugin's DPI adjustments. For 99% of plugins, there's usually a setting that will work for the plugin - iZotope being a notable exception, although I believe they are aware of the issue and are working on it (it's not just Sonar that has scaling problems with some of their plugins).

FYI - to stop MIDI Output being enabled on newly inserted synths: 1. Open Synth Rack View 2. Click on the "Insert Synth Options" dialog button 3. Ensure "Enable MIDI Output if Available" is unchecked, then click OK.

We're aware of this issue, and have fixed it for the next release. The workaround for the moment is to disable the Spectrum Analyser display in the Inspector / Console View before loading/saving ProChannel presets.

Another thing it could be is an archive file on your desktop that Windows explorer is unable to unzip. The Browser control within Cakewalk is basically an instance of Windows Explorer, and when it is first instantiated it points to the desktop. If there are any files there that Windows Explorer can't deal with, you may get a shell exception. One way of confirming this is to open Windows Explorer and go to your desktop - if Windows Explorer hangs or crashes, then that's your issue.

@Archerdrummer - does turning off the spectrum analyser in the console view help at all?

My hunch is that it's this setting here: When this is checked, all CC's are set to 0, apart from CC7 which is set to 101. Normally, having both "Zero Controllers When Play Stops" is fine as long as you've also got "MIDI Event Chase on Play" checked too... that way any CC changes are set to the correct value when you continue playback. CC7 events should be fine. CC7 automation will be problematic if you have jump events, as they literally mean "no automation" - so nothing will be chased. You could try unchecking "Zero Controllers..", but this will require you adding your own resets for any CC's / Pitch Bend at the beginning of each MIDI track. My recommendation: 1. Ensure you're setting CC7 to what you want at the beginning of the project. 2. Ensure "MIDI Event Chase on Play" is checked. 3. If you must use CC automation, avoid jump envelopes. 4. If possible, use audio volume automation instead.

The new Sonar supports articulations that apply negative delay in either ticks or ms (up to +/- 1000 ms or +/- 1000 ticks). Negative delay at the track level is in the works, but no ETA as yet.

Radius and Elastique use completely different algorithms to stretch the audio. There is no better algorithm between the two - one can be better for one type of audio, and the other the better for another. All stretching algorithms will create artefacts / distortion to some extent - again, the extent of these artefacts will depend on the audio and how much you're stretching.

This might work... 1. Open up RegEdit and navigate to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\ASIO 2. Expand that node, find your Axe Fx ASIO device, and expand that. 3. Take note of the exact CLSID and description. 4. Take a backup copy of drivercompat.json in C:\ProgramData\Cakewalk\Sonar (or C:\ProgramData\Cakewalk\Cakewalk Core for CbB ) 5. Open drivercompat.json in notepad 6. Add an entry for the Axe Fx, using the CLSID (minus the curly braces) in step 3 as the uuid, and the description as the name. Be careful to ensure you get the syntax exactly right, then save the file. This will tell Sonar to ignore the Axe Fx as an ASIO device.

I wholeheartedly agree with all the replies here. What I would suggest is maybe getting someone else to mix one of your songs, just so you can compare to your own. There are bound to be plenty of up & coming mixing engineers who would be more than happy to do a mix far cheaper than you'd expect, just so they can get some experience / add to their portfolio. There was a youtube video not long ago, where the youtuber paid 5 mixers and 5 mastering engineers of different price scales to a mix / master. The best master came from some on fiver.com, and cost something like $20. A similar thing happened with the mix.

Do your microphones have switchable patterns? If you're used to using cardioid, you'll be used to getting a proximity effect which boosts bass frequencies giving a fuller sound. If you've switched it to something else, like omni or figure of 8, that could explain the difference in sound.

Both Sonar & CbB enumerate all audio interfaces on start up, so it can correctly show which ones are available. Depending on how the drivers are written for those interfaces, it could cause a temporary glitch in any existing audio being played.

Have you inadvertently turned on high pass (either on the mic or the pre-amp) ?

Unfortunately that's up to the VSTi vendor. In fact, it's not just VSTi's - some hardware synth modules ignore CC7 for volume. IIRC I've got one or two Korg modules that ignore CC7 unless they're in GM mode.