Sonar 6 and Pan Laws

Eric ...

In Sonar 5 (as I'm sure you know) pan laws were saved on a per project basis, not retrospectively applied to old projects as some sort of global option. I can't believe that Cake would have been so foolish as to change this for S6, though I'm still waiting for mine. Gee, I hope you've made a mistake here (if you see what I mean) because if this is true we're really in the poo when it comes to opening old projects that are "work in progress".

Please be wrong! And please, please, can anyone confirm what is (or isn't) happening here. I feel an attack of advanced paranoia coming on.

Best,
Geoff

Wow! Thanks for posting this Eric. If this is a general phenomenon the consequences will be pretty serious for people.

Confirmed as well.

ORIGINAL: donald

I thought that was a global option in S5 as well.

donald:

In Sonar 5, the default panning law for new projects is determined by whatever setting has been saved with the template file on which the project is absed.

You can change it, however, for individual projects, and those changes are saved with the file.

Best,
Geoff

SONAR5:
The Pan law displayed in the Audio options is that of the active project.

SONAR6:
The Pan law displayed in the Audio Options is the global "sticky" setting (now saved in Aud.INI). This becomes default for new projects.

This is a bit confusing. So you theoretically could have no idea what your present pan law is for your current project b/c the one being displayed is the 'global' one for 'future' projects ???

The Pan law displayed in the Audio Options is the global "sticky" setting (now saved in Aud.INI). This becomes default for new projects.

eek. I think the Pan law displayed should always be that of the active project....probably the bug in S5 shouldn't be considered a bug at all.

Absolutely

ORIGINAL: corrupted

Yea, I'm confused. If I always left that as the default law, should I have no problems?

ORIGINAL: glazfolk
Use that status bar to display Panning law and Latency information, to name but two.

And the length of the current selection! (to take it way of topic)

If you load someone else's project, you will get THEIR pan law just as you always did. The confusion is that you can't display the pan law for that particular project. We'll look at showing the current project pan law in the UI. Again, sorry for any confusion this causes.

ORIGINAL: clogdivermusic

So if someone FTP delivers me a bundle to work on unless I ask them the panning law they set, I cant get it unless I ask ? freaky...

Am I missing the point on this. Project colaboration is important to me.

Something not quite kosher here.

I tried bouncing a clip to another track and the overall volume of the bounced clip is either 3 db higher or lower than the original depending on how I have the panning laws configured. I don't want a 3 db change. I want the bounced clip to retain the same volume levels. Always. Something has changed in SPE6 in regards to this. The clips I am experimenting with are mono clips on a mono track and I am bouncing to a mono track. Panned center.

Can anyone confirm this or perhaps shed some light on this? Could this be a bug?

I gotta chime in and say that from what I'm understanding from this thread, I'm not too thrilled about the Pan Law configuration now... Only a Global display in Options, but still a Per-Project control... what's the logic behind this? I dug the Per-Project aspect of Pan Law, both in display AND utilization. I'd like to know why the change from this at all.


Larry-

Here is what I found to be the bug in Sonar 5... I'm assuming this is what you've encountered in 6 now?

In Sonar 5.0 & 5.0.1, applying a Bounce to Clip on a mono clip causes the gain to change if the panning law is anything other than one of the 0dB options. On testing, it seems if there is any mono context in the chain, (be it the clip and/or the track) the clip bouncing will follow the pan law. The problem is that on a mono clip in a mono interleaved track, the only desired effects when bouncing are to apply any clip FX, fades, envelopes, and combining of selected clips... we don't want the volume of the clips to shrink.

In this scenario, any clip pan envelopes should be ignored (even though using any would be pointless anyway), since the TRACK interleave switch is set to mono, so therefore the pan law should have NO bearing at the clip level, since it is being applied at the track level. It is redundant to do so.

This happens to mono clips on stereo interleaved tracks as well, but the gain change here is wanted... the only problem is that the resultant clip (from bouncing) should be a STEREO clip. That would prevent it from being effected by the pan law again as it's played through the stereo interleaved track after the bounce. (Note: applying the Bounce To Clip function to a stereo clip which resides in a track with its interleave switch set to mono results in a mono clip. However, bouncing a mono clip in a stereo interleaved track currently does NOT, but SHOULD, result in a stereo clip.)

I'm no programmer, but I would think all you'd need to do to fix this would be to add two conditional lines to the Bounce to Clip code:
- IF the track interleave switch is set to mono, do not apply the pan law during the bounce, and make the resultant clip mono.
- IF the track interleave switch is set to stereo, apply the pan law during the bounce, and make the resultant clip stereo.

Freezing a track produces the correct mono/stereo version of a resultant clip (based on the tracks' interleave settings), but unfortunately, Bounce To Clip does not produce stereo resultant clips, only mono ones.
...Also to note: Freezing a track with its interleave switch set to mono results in the unwanted gain drop as well.

Wacky stuff.

(never mind...)