2CAudio Precedence | 1.5 | Move Out Of Flatland. Take Precedence.

[jens]

How many tracks in your mix do you actually spend applying pan automation to as a % of your total tracks? Less than 10% on average? It is mostly a special FX need IMHO.

I never counted it - why would I?

It certainly is not a special FX. I refer to arrangement. I refer to quite traditional methods of mixing. I refer to good practice.

[jens]

That's another thing. Would be nice, of course.

But Precedence is supposed to replace the pan of its host and to be used on every track, so the lack of the possibility to automate Angle means we are supposed to give up automating pan altogether in order to use Precedence. Just let that sink in for a minute.

i don't really see it that way ...
precedence seems designed to construct a virtual soundstage ,
and place your elements upon that stage .

i am not looking for the oboes to stand up , grab their chairs ,
and move away from the tympani , all while performing ...

i have used precedence to augment my DAWs panning , in that
i have placed an element with precedence , and then automated
the panning of that channel w/ the DAWs panning control while
leaving the precedence placement untouched . the results range from subtle ,
to striking , depending on the material , and amount of movement ...

is this meant to take the place of "pan" controls on tracks?
In other words - pan everything (using precedence/breeze 2) at center - and use Precedence to place things L or R (as well as depth)?

yes!

ALL YOUR PAN R BELONG TO US!

Looks like I have something to sell then - move along folks, nothing to see here.

(If the developer thinks changing the pan of a track somewhere in a song is a "special FX" I'm out )

[Andrew Souter]

Trust me, if we had a magic wand to just add smooth automation to everything, without major negative consequences, we would have already. Sadly we don't. This hasn't changed. We've heard the request, but it is more or less incompatible with the current design goals. Something for the future perhaps, but it won't make this next update for sure. What else can I say on this really?

(If the developer thinks changing the pan of a track somewhere in a song is a "special FX" I'm out )

point is, static panning is statistically much more common than pan automation... if the goal is simply to have some instrument center during chorus and left during verse or similar such things, you can of course just use two different tracks. "Arrangement" needs are no problem. Only smooth continuous changes and motion fx are are issue bc the tool has not been designed for this and to do so would skyrocket the CPU-usage, and there are other tools for such things as others have mentioned...

Anyway, we heard the request a few months ago. We are aware of the desire. But refer to the above and my previous post...

[jens]

I didn't ask for smooth, did I?

I know that will take longer to implement.

But it's more or less just one line of code for you to simply add it to the list of automatable parameters, isn't it?

[bmanic]

I automate pan all the time. It's probably the most common parameter to automate after volume and sends.

So yeah, I agree with Jens. If it glitches with slow pan automation then so be it.. I'd be more than happy to use it with "binary" automation (jumping from one value directly to the next intended one), no real need for smoothness.

[Sampleconstruct]

Panning things over time creates movement, no?

[jens]

Panning things over time creates movement, no?

Perhaps, depending on your own perspective, requirements and so forth...

Here it creates room.

[jens]

I'd be more than happy to use it with "binary" automation (jumping from one value directly to the next intended one), no real need for smoothness.

Yes, I could live with that too.

[Andrew Souter]

I didn't ask for smooth, did I?

I know that will take longer to implement.

it seems semantically implied, and Plexus seemed to read it the same way which reinforced the interpretation, and he seemed to attempt to contrast your point by making the explicit distinction between non-continuous vs continuous automation...

but, ya, after reading what you wrote again, I do not see the word smooth in your post, no. If I misinterpreted mea cupla.

But it's more or less just one line of code for you to simply add it to the list of automatable parameters, isn't it?

To expose the parameter to automation is simple yes. What happens when you attempt to automate it is somewhat unknown though, as there are other complications which you can not see ye bc you don't have the version we are working on.

If people are content to have non-continuous, jump to new value with potential click/noise if it happens during audio playback, variety of automation, we could possibly attempt to expose the parameter.

We will likely need to have some public/customer beta period of the new version due to the changes. We could perhaps try it during that and see what everyone thinks and see if it causes any other headaches.

[martinjuenke]

However, I think Precedence is improving a mix when used carefully and thoughtfully...

[martinjuenke]

I didn't ask for smooth, did I?

I know that will take longer to implement.

it seems semantically implied, and Plexus seemed to read it the same way which reinforced the interpretation, and he seemed to attempt to contrast your point by making the explicit distinction between non-continuous vs continuous automation...

but, ya, after reading what you wrote again, I do not see the word smooth in your post, no. If I misinterpreted mea cupla.

But it's more or less just one line of code for you to simply add it to the list of automatable parameters, isn't it?

To expose the parameter to automation is simple yes. What happens when you attempt to automate it is somewhat unknown though, as there are other complications which you can not see ye bc you don't have the version we are working on.

If people are content to have non-continuous, jump to new value with potential click/noise if it happens during audio playback, variety of automation, we could possibly attempt to expose the parameter.

We will likely need to have some public/customer beta period of the new version due to the changes. We could perhaps try it during that and see what everyone thinks and see if it causes any other headaches.

I don‘t like clicks! I used to love chicks, but that times are gone...

[experimental.crow]

Panning things over time creates movement, no?

Perhaps, depending on your own perspective, requirements and so forth...

Here it creates room.

out of curiosity , have you tried the method i outlined below ?..

i have used precedence to augment my DAWs panning , in that
i have placed an element with precedence , and then automated
the panning of that channel w/ the DAWs panning control while
leaving the precedence placement untouched . the results range from subtle ,
to striking , depending on the material , and amount of movement ...

[jens]

I didn't ask for smooth, did I?

I know that will take longer to implement.

it seems semantically implied, and Plexus seemed to read it the same way which reinforced the interpretation, and he seemed to attempt to contrast your point by making the explicit distinction between non-continuous vs continuous automation...

but, ya, after reading what you wrote again, I do not see the word smooth in your post, no. If I misinterpreted mea cupla.

But it's more or less just one line of code for you to simply add it to the list of automatable parameters, isn't it?

To expose the parameter to automation is simple yes. What happens when you attempt to automate it is somewhat unknown though, as there are other complications which you can not see ye bc you don't have the version we are working on.

If people are content to have non-continuous, jump to new value with potential click/noise if it happens during audio playback, variety of automation, we could possibly attempt to expose the parameter.

We will likely need to have some public/customer beta period of the new version due to the changes. We could perhaps try it during that and see what everyone thinks and see if it causes any other headaches.

I'd be more than happy to help testing.

As it is now I have to duplicate a track that uses Precedence if I want to change its pan, which - as you will probably admit - is neither very practical nor ressource-friendly.

[jens]

out of curiosity , have you tried the method i outlined below ?..

No, that's no good for me. I don't use pan-automation to create an effect. Ideally in most cases I don't want it to be noticeable at all.

[cthonophonic]

I'd be more than happy to use it with "binary" automation (jumping from one value directly to the next intended one), no real need for smoothness.

Yes, I could live with that too.

Can you not already do this? I can automate Angle easily here.

EDIT: "here" being in Jeskola Buzz, so maybe it sees a larger set of parameters exposed than traditional DAWs? (no idea if that's the case)