dantarbill

I'm seeing a lot of traffic about what I'm thinking is a fairly few users about special edge case issues with 2025.02 (31.02.0.077). Could I make the assumption that, on the main, this release is stable and installable...or am I just being lazy and failing to read between the lines? Thanks for your reasonable responses.

The template in question is post ProChannel, so at least that won't be an issue.

Is there any possibility of problems using a Project Template that I've been building on since Sonar was first introduced? Should this all be backwards compatible with 2024.12?

I have a number of legacy (32 bit) projects that were built using the old Session Drummer 3 (SD3). Trying to use that MIDI data with Addictive Drums 2 (AD2) is yielding poor results. Trying to use SD3 doesn't work because it claims to not be installed correctly. It would appear that the SD3 content is actually there, because there's a SessionDrummer.dll file dated 09/12/2013 in my 32 bit VST(i) path... C:\Music\Plugins\VSTi\32\Cakewalk\Session Drummer 3 ...as well as a Contents sub folder with Kits, Patterns and Programs. What's odd is that I also still have Session Drummer 2 from previous versions...and it works without issues. I guess this comes down to 2 different questions... What was the last Sonar release that included Session Drummer 3? (And/or how do you get it reinstalled) How do you make drum mapping work to make SD3 MIDI content work with AD2? Thanks for your help.

I have a number of legacy (32 bit) projects that were built using the old Session Drummer 3 (SD3). Trying to use that MIDI data with Addictive Drums 2 (AD2) is yielding poor results. Trying to use SD3 doesn't work because it claims to not be installed correctly. It would appear that the SD3 content is actually there, because there's a SessionDrummer.dll file dated 09/12/2013 in my 32 bit VST(i) path... C:\Music\Plugins\VSTi\32\Cakewalk\Session Drummer 3 ...as well as a Contents sub folder with Kits, Patterns and Programs. What's odd is that I also still have Session Drummer 2 from previous versions...and it works without issues. I guess this comes down to 2 different questions... What was the last Sonar release that included Session Drummer 3? (And/or how do you get it reinstalled) How do you make drum mapping work to make SD3 MIDI content work with AD2? Thanks for your help.

Is anyone out there not using a mixer in their setup and just using Input Echo to monitor with FX? Thanks

For many years, I had been using a Yamaha 01v and ADAT as my audio interface. This let me use the 01v’s FX to “wet down” the monitor mix in the headphones to keep vocal clients (mostly me) warm and happy. I’ve since started using a Cranborne 500R8 rack as my interface (better preamps and more than 18 bit ADC’s). The problem is, in order to wet the monitor mix, I have to turn on the Input Echo. I thought I could live with the comb filtering caused by the latency…but then I tried it with a “not me” client, and she wasn’t having it. I’ve come up with a hack to get around it. I’m taking a signal from the vocal pre’s insert and feeding it back to the mixer and using that to monitor and wet the signal. However…I’m wondering why I’m hearing the flangey, comb filtery thing in the first place. Am I somehow getting the early vocal signal mixed into my monitoring chain, or is that just happening “in my head” as it were? Does everyone using Input Echo just live with this, or is there something wrong with the way I’m routing stuff? My current setup shows 1.5 ms (64 sample) buffers (44.1 kHz) for a round trip of 6.4 ms. (Version 2024.02)

iZotope RX! (Standard is fine. You don't need the uber expensive Advanced edition.) It will seem like an expensive way to solve a limited problem, but after you have it, you'll wonder how you did without it. Gates can work too...but there's a lot of work involved in getting it dialed in right...and it doesn't deal with the veil of noise under the signal.

I've checked and rechecked... Any settings I make in "Selection after single split:" do NOT change the default behavior. It always acts as if I have "None" selected as the default behavior. Same is (was) true for the "Default Fade-In Curve>" and "Default Fade-Out Curve>". Ah HA!! I found it! The problem was that I had "Auto Crossfade" selected. That caused what I'll consider unintuitive behavior where it applied the Crossfade defaults when I split. I'm not sure if I had changed the "Auto Crossfade" selection or that behavior had changed with the new update...but I'm back in business.

Sorry...you're right. It's just S for Split and K for clip mute.

What I'm saying is that the config setting is getting ignored by 2023.09. On my system, there's currently no way to change the default behavior of Split or the Crossfade behavior.

I'm not sure if some default settings got changed with the 2023.09 update, but I'm seeing new and unwanted behavior... When I split a track (with "S"), typically the left side of the split is selected. So, if I subsequently hit "K" to mute the selected track portion, it mutes to the left. Now, it seems that neither is selected, so you have to explicitly select one side or the other. Also, the default crossfade (Options/Crossfade Type>Default Fade-In/Out Curve settings seem to now be completely ignored. What happened and how do I fix it? (I just checked Preferencess/Customization/Editing/Clips Selection after single split:. It's set to "Left Portion (default)". This strongly suggests that something in 2023.09 got broke or regressed.)

>...these days nobody should be using 44.1 or MP3 files. Sorry...still unapologetically using both all the time.

I think I might have found the sweet spot! So...the math looks like this...for a 48 kHz file... 2,147,483,647 (data length) / 3 (bytes per 24 bit sample) / 2 (for stereo) / 48,000 (samples/second) = 7,456.54 seconds / 60 (seconds/minute) = 124.28 minutes. Noting again that this is likely the data length rather than the file length, 2 hours and 4 minutes might not be the absolute max, but I don't currently know what order of magnitude the wav header is (which is variable anyway). I'm doubting that it's more than 288,000 bytes (which is one second of stereo 24/48 audio). The audio capture I have for today happens to be 2:03:45 in length, which should be under what I'm postulating as the "I'm giving up and converting" point. SonarWalk (Cakenar?) swallowed it without complaint! For my previous 44.1 kHz example, the math works out to 136.71 seconds max, which at 02:16:42 may be right around the hairy edge of the max. Have I answered my question?

Unfortunately, that's not the problem. The import bit depth is "Original". If not, it would, as you say, convert everything on import. Instead, it's only converting WaveLab created stereo 24/44.1 (or 24/48) files that are longer than some value that's more than somewhere over like an hour and a half, but I don't know what that critical point is yet. Thus the question. That critical length is likely to be file size based rather than time/length based since .w64 was partly an effort to sidestep a 32 bit file length (or data length?) descriptor in the original wav file header chunk spec. Hmm...the max unsigned 32 bit integer is 4,294,967,295. What if WaveLab is representing that as a signed integer? Then that would be more like 2,147,483,647. Maybe that's it...because...in the case above...it's less than the resulting file size. Cake dev's? Comments?