Could someone tell me why Bounce To Clips applies panning law?

...

I just don't understand why Sonar will apply panning law and cut 3db when bouncing mono clips with the Bounce To Clips command. I can manage my levels just fine without arbitrary adjustments made if I use V-vocal or just bounce an edit. It's F'ing useless if it changes my mix. I'm surprised more people don't complain about it.

I'm grumpy. I've been doing minus 1's all night and It's just too boring.

Good on ya! Wm

It is a long standing (unacknowledged) bug. The only way around it is to work at the default 0db pan law.

I work at -3db center, sin/cos taper. however, in SONAR I switch to 0db center before bouncing to mono clips.

Maybe I will make this my personal crusade and whine endlessly about it. I've posted before regarding issues of pan law and Sonar so I have a history of posts on the subject. I'm not an expert but I could never be accused of being an also-ran on the subject.

Here goes:

BAKERS PLEASE FIX BOUNCE TO CLIPS!!!

It is ruining the world and you don't seem to notice. Look out side! The global economy is collapsing. The US auto companies are on the verge of extinction. People are losing their homes. Season 4 of The Wire hasn't arrived in my mailbox yet. Gloom, despair, agony on me.

Changing pan law to bounce clips (I do this too) is really a pathetic work around for a basic editing function.

FIX IT ALREADY!


I approve this message

My preference is to work at -3db center, but I got tired of going into Audio Options and changing the pan law, just for a simple mono bounce. It is pretty mind boggling that this has never been addressed. I think you might even find that Cakewalk thinks this is how it is supposed to work! I've reported it a few times, but it has never been acknowledged.

Wow this is unacceptable. I'll be reporting this one right away. Thanks goodness for 0dB pan laws.

...it's hard enough to get our creatives juices running as it is. It's even worse when we have to fiddle endlessly with obstacles...

This is another of those many dozens of Sonar bugs that just never get resolved, and this makes Cakewalk appear to the world as a Mickey Mouse outfit run by two or three nerds in the basement to most industry professionals.

I complain about this bush-league management style on a regular basis, but it doesn't seem to change matters. I have never understood why Cakewalk executive management allows this shameful incompetence to continue in Sonar engineering management. Frankly, it's embarrassing, and as a user who expects little bugs to disappear in the natural course of things, it's damn frustrating! I sincerely wish they'd demonstrate more professionalism in this all important area of software support. The industry has come a long way in the past 25 years in understanding that there's much more to developing a great software product than writing code. If Cakewalk can't find skills in-house, then hire an experienced manager who understands how to put current software support methodology into practice.

Gee, you learn something new every day. Today I learned about a problem I didn't even know I had!

By the way, it does this weirdness when you freeze a track, too.

Fortunately, I use the 0db pan law and had never experienced the phenomenon until just now, when I was motivated by this thread to try and reproduce the odd behavior. It does indeed appear to be a bug; I cannot think of any other logical explanation for it.

Have any of you actually opened a support ticket for this issue? Or have you just read other peoples' posts and just assumed that it has been reported?

If it is indeed a "long standing (unacknowledged) bug", that would be indicative of a strangely cavalier attitude on the part of CW engineering. However, such implied arrogance just doesn't jibe with my experience with them. Something doesn't compute.

ORIGINAL: bitflipper

Gee, you learn something new every day. Today I learned about a problem I didn't even know I had!

By the way, it does this weirdness when you freeze a track, too.

Fortunately, I use the 0db pan law and had never experienced the phenomenon until just now, when I was motivated by this thread to try and reproduce the odd behavior. It does indeed appear to be a bug; I cannot think of any other logical explanation for it.

Have any of you actually opened a support ticket for this issue? Or have you just read other peoples' posts and just assumed that it has been reported?

If it is indeed a "long standing (unacknowledged) bug", that would be indicative of a strangely cavalier attitude on the part of CW engineering. However, such implied arrogance just doesn't jibe with my experience with them. Something doesn't compute.

As I already said, I just don't understand they're attitude either. I didn't report this one, but I do recall it being mentioned on the forum more than once. There are certainly others I've reported and never got a response, for instance, the one about the unmutable muted events using the Mute tool for which there's a recent post.

I'm sure you know that it's a common management practice to assign non-critical bugs to the developers, and they're intended to work on them in their spare time. I've worked both sides of this practice, both as a coder and as an engineering manager in the over 30 years I spent in the software business.

With each minor release, these kinds of bug fixes get rolled into the build, to the benefit of users new and old.

Why doesn't this kind of thing happen with Sonar?

ORIGINAL: bitflipper


Have any of you actually opened a support ticket for this issue? Or have you just read other peoples' posts and just assumed that it has been reported?

Yes, as stated earlier, I reported this right away.

Heh, so that's the root of the reason I stopped bouncing to clips? Never understood why the clip got quieter. I'm about to open a ticket. How hard could that be to fix? Make sonar switch pan laws to 0 automatically while bouncin to clips. Does it do that with Bounce to tracks too?

Make sonar switch pan laws to 0 automatically while bouncin to clips.

It's fundamental!

ORIGINAL: kwgm

This is another of those many dozens of Sonar bugs that just never get resolved, and this makes Cakewalk appear to the world as a Mickey Mouse outfit run by two or three nerds in the basement to most industry professionals.

I complain about this bush-league management style on a regular basis, but it doesn't seem to change matters. I have never understood why Cakewalk executive management allows this shameful incompetence to continue in Sonar engineering management. Frankly, it's embarrassing, and as a user who expects little bugs to disappear in the natural course of things, it's damn frustrating! I sincerely wish they'd demonstrate more professionalism in this all important area of software support. The industry has come a long way in the past 25 years in understanding that there's much more to developing a great software product than writing code. If Cakewalk can't find skills in-house, then hire an experienced manager who understands how to put current software support methodology into practice.

Can anyone say External Inserts? But now, if we talk about what pretty colors we can add to Sonar then they're all over it. Go figure.

Been like this since pan law options were introduced. Pan law options in SONAR were the direct result of the Shea 20/40% better in Nuendo thread. Twenty thousand inflamed posts later... turned out he actually had a valid point. We got pan law options, but the bounce to mono clips needs to be fixed.

ORIGINAL: LSinBTonez

Does it do that with Bounce to tracks too?

No (scratched). The answer is YES.


EDIT: Corrected.

I need to bounce mono vocal takes to a composite mono track all the time. No real mixing going on, just selecting optimal phrases from multiple takes with volume envelopes. If I select a mono destination in the bounce to a new track, it cuts the levels. But I noticed that if I select split-mono destination format, it leaves them alone. So I do that and delete the extra mono track. I think it leaves them alone too if you select a stereo format for the new track, but then you're stuck with a double-sized composite track.

Howard

ORIGINAL: Jose7822

ORIGINAL: LSinBTonez

Does it do that with Bounce to tracks too?

No.

Yes.

Exactly 3db gain reduction when bouncing a mono track to another mono track when using the -3db center, sin/cos taper pan law. Currently in SONAR you must switch to the 0db center pan law before bouncing to mono clips or tracks if you want to avoid this loss in gain.

In SONAR 7 and 8 at least, there are two choices for "0". Which one would be better to avoid this problem if you want to just 'set it and forget it'?

The default is the first choice:

(Default) 0 dB center, sin/cos taper, constant power--this choice causes a 3 dB boost in a signal that's panned hard left or right, and no dip in output level in either channel when the signal is center panned.

But it seems to me reading the Help that the last choice might be better as the default:

0 dB center, balance control----this choice causes no boost in a signal that's panned hard left or right, and no dip in output level in either channel when the signal is center panned.

SteveD,

You're right. I guess I didn't do it right when I tried this last night. Thanks for correcting me.


Riojazz,

There are actually 3 "0dB center" pan laws in Sonar 7/8. Either one will work fine but I personally stick to the default pan law which is the first one on the list.



Take care!

Which one would be better to avoid this problem if you want to just 'set it and forget it'?

0db center, sin/cos taper, constant power. This is the default because it's essentially no automatic compensation and therefore most accurately emulates what happens in the physical world when mono sources are acoustically blended.

Very good, thank you both.