Automation of Same Colored Controls In Same Area Challenge

[Todd R]

I've since figured out that the last item (on the right) is for automation specific to individual plugins patched on input channels.

all three are for that purpose.

I.e. RML-wrapper (non-native) plugin bypass or native plugin parameter automation.

this is not clear...I will clarify below after testing in SS64

Oh, and no cursor placement needed for the pre-vs.-post-fader-FX patch-bypass-state automation. Just choose the one you want from those two on the list.

Actually your explanation is not clear enough. The Input FX-Pre Sw and Input FX-Pre Sw are a native virtual mixer control, so operates on one mixer control graphic. Input FX Plugin has multiple possibilities (keep reading)

I tested directly in SS64 the one on the RHS using the exact syntax as in my post above (Input FX Plugin) which operated as I described and which you have now tested (a bit) :-)

The Input FX-Pre Sw and Input FX-Post Sw do not show the engage/ bypass events of a VST in a SAW Wrapper for non-native FX in the Pre and Post patches; Input FX Plugin shows those.

So why are you assuming I meant the Input FX-Pre Sw and Input FX-Post Sw? I did not mention those before now. Maybe you only tested a single Pre or Post VST and automated one wrapper?
For Input FX Plugin, I tried both Pre and Post instances and automated in the same track and that is what I explained above yet neglected to say that I tested both Pre and Post in the same Input track with multiple VSTs in each Pre and Post slot, my bad comms.
The cursor position will filter to the specific Pre or Post wrapper's event/ entry and more than that!

Which has led me to discover that the Input FX Plugin will allow users to filter each separate VST wrappers' events based on cursor position! That I did not know and have needed for years now.
Cursor needs to be later than a wrapper engage/bypass event entry in the timeline to "bind" to that event/ entry's wrapper. This binding of the filter to a specific wrapper will hide the other wrappers' engage/ bypass states (if more than one)
and if left-drag cursor/ marked area> the other wrapper's events/ entries conditions do not show on other wrappers' engage/ bypass graphic. Actually a quite powerful feature.

The Input FX-Pre Sw and Input FX-Post Sw events are for engage/ bypass on specific mixer channel U-Link graphic; (which I did not understand until I tried it just now).
Input FX Plugin, Input FX-Pre Sw and Input FX-Post Sw basically do the same operation at different places in the Virtual Mixer routing flow.
Dave, thanks for pointing this out, now I will try using the Input FX-Pre Sw and Input FX-Post Sw switches in future :-)

Thus users have multiple levels of control! Single VST (Input FX Plugin) and group controls (Input FX-Pre Sw and Input FX-Post Sw switches)

These discussions always seem to lead to learnings :-D

[jmh]

Cursor needs to be later in the timeline to "bind" to a wrapper. This binding of the filter...

I use the filter regularly when playing with automation. I thought the filter engaged with the nearest entry - not the previous. I must tend to put the cursor behind (or on as I cntr-tab or cntr-shift-tab a bit too), because it usually works. Occasionally I find myself in an unexpected parameter - and I may think I'm making an adjustment on one parameter, and assume I must have applied the filter near the wrong event - but I was actually on the wrong side.

I also understand why popping up the filter list can only contain so many items, but it would be cool if a detail box could contain things like levelizer-comp-bypass - but one of the things about plugins is they are just that - a separate part, and something seeming simple may be prohibitively difficult.

In any case I'm glad you mentioned 'later in the timeline'.

These discussions always seem to lead to learnings :-D

Could be true...

[Todd R]

I use the filter regularly when playing with automation. I thought the filter engaged with the nearest entry - not the previous. I must tend to put the cursor behind (or on as I cntr-tab or cntr-shift-tab a bit too), because it usually works. Occasionally I find myself in an unexpected parameter - and I may think I'm making an adjustment on one parameter, and assume I must have applied the filter near the wrong event - but I was actually on the wrong side.

Well, looks like I'm partly correct, from the manual:
"The current type will be defined by the last automation entry at or before the current cursor position.
You can select a type by simply dragging the cursor within a group of entries or [Ctrl-Tabbing] to an exact entry."
At? On? In the same time location is what is meant. Therefore, ctrl-tab/ ctrl-shift-tab is our friend here. Yes, I use ctrl-tab/ ctrl-shift-tab working in SS daily.

I also understand why popping up the filter list can only contain so many items, but it would be cool if a detail box could contain things like levelizer-comp-bypass - but one of the things about plugins is they are just that - a separate part, and something seeming simple may be prohibitively difficult.

I'd like the ability to user define the the automation entry/ event color

In any case I'm glad you mentioned 'later in the timeline'.

Well, like I said, partially correct :-)

So here we are doing our best to understand:
"A special feature allows all Fx plug-in automation data types to be shown at once if the cursor position is not directly behind an Fx automation data type when selecting this option.
If the last tracked data type is an Fx automation type, only that specific type will be displayed."
yeah, uh sorry, that's just not clear at all; only way user is learning how to do this is in practice and consider many possible scenarios.

[Dave Labrecque]

>>I've since figured out that the last item (on the right) is for automation specific to individual plugins patched on input channels.<<

all three are for that purpose.

I don't see how. The first two are not for individual plugins' automation but for patch module bypass states.

>>I.e. RML-wrapper (non-native) plugin bypass or native plugin parameter automation.<<

this is not clear...I will clarify below after testing in SS64

Well, it was clear to me.

>>Oh, and no cursor placement needed for the pre-vs.-post-fader-FX patch-bypass-state automation. Just choose the one you want from those two on the list.<<

Actually your explanation is not clear enough. The Input FX-Pre Sw and Input FX-Pre Sw are a native virtual mixer control, so operates on one mixer control graphic.

What? Each operates on one. That's two total. What's the problem?

The Input FX-Pre Sw and Input FX-Post Sw do not show the engage/ bypass events of a VST in a SAW Wrapper for non-native FX in the Pre and Post patches; Input FX Plugin shows those.

Right. Which is what I said.

So why are you assuming I meant the Input FX-Pre Sw and Input FX-Post Sw?

Because the way I understood what you described seemed to fit the way those function. Except the cursor-placement stuff seemed unnecessary. I thought you'd misunderstood which filter I was asking about, despite the fact that you called it the right thing.

I think I would've understood what you meant if, instead of...

[INDENT]"Input FX PlugIn chosen shows both pre and post patched FX"[/INDENT]

...you'd written:

[INDENT]"Input FX PlugIn chosen shows both pre and post patched individual plugin automation"[/INDENT]

Which has led me to discover that the Input FX Plugin will allow users to filter each separate VST wrappers' events based on cursor position! That I did not know and have needed for years now.

Woah. I did not know that.

Cursor needs to be later than a wrapper engage/bypass event entry in the timeline to "bind" to that event/ entry's wrapper. This binding of the filter to a specific wrapper will hide the other wrappers' engage/ bypass states (if more than one) and if left-drag cursor/ marked area> the other wrapper's events/ entries conditions do not show on other wrappers' engage/ bypass graphic. Actually a quite powerful feature.

A couple things to say here. The "binding" rules are a little more broad. I find that the "bound" automation type is defined by the type at or closest prior to the cursor's location. I.e. ctrl-tab to--or place the cursor just after--your type of choice. Additionally, when making this cursor placement, you must be working in the current HotTrack--which is usually the case by virtue of how we typically work. A couple times, though, I was dragging in an adjacent track (inadvertently making it the HotTrack) when choosing my "key" automation entry, and when I selected the filter, it didn't work as I'd intended. I presume this requirement is not specific to this particular view filter.

Other thing to say: marked areas have no impact that I can see. I think you're just getting the normal behavior of the view filter: it's all determined by the "key" automation entry, which, as we've established, is up to the cursor and HotTrack.

The Input FX-Pre Sw and Input FX-Post Sw events are for engage/ bypass on specific mixer channel U-Link graphic; (which I did not understand until I tried it just now). Input FX Plugin, Input FX-Pre Sw and Input FX-Post Sw basically do the same operation at different places in the Virtual Mixer routing flow.

RE: specific-channel graphics... I don't believe this is true. As with other filters, the view of all automation of that type across the MT are filtered.

RE: the three filter types doing the same thing in different places... beg to differ. The first two are limited to bypass state and work across all input channels at once. The last one can filter all available plugin automation and can be focused to a specific automation type for an individual plugin instantiation. This appears to be unique to this filter type.

Dave, thanks for pointing this out, now I will try using the Input FX-Pre Sw and Input FX-Post Sw switches in future :-)

You betcha.

Thus users have multiple levels of control! Single VST (Input FX Plugin) and group controls (Input FX-Pre Sw and Input FX-Post Sw switches)

These discussions always seem to lead to learnings :-D

Indeed. Thanks for the heads-up on that per-instantiation filtration thang!

Hold on. Now you got me thinkin' that you haven't even scratched the surface of individual(native)-plugin automation types. Say it ain't so! And sorry I haven't (apparently) extolled the virtues of said functionality sufficiently. Check this out (unless I'm an idiot and you're totally on-board with this already):

Load a Levelizer or a native Paragraphic EQ. Put a blank region somewhere down the timeline if ya gotta. Put the MT in Automation Mode. Hit the spacebar. Start moving knobs and stuff on that native plugin. Different knobs. Different stuff. Hit the spacebar.

Now move the cursor around and engage your new favorite view filter.

[Todd R]

>>I've since figured out that the last item (on the right) is for automation specific to individual plugins patched on input channels.<<



I don't see how. The first two are not for individual plugins' automation but for patch module bypass states.

>>I.e. RML-wrapper (non-native) plugin bypass or native plugin parameter automation.<<



Well, it was clear to me.

>>Oh, and no cursor placement needed for the pre-vs.-post-fader-FX patch-bypass-state automation. Just choose the one you want from those two on the list.<<



What? Each operates on one. That's two total. What's the problem?



Right. Which is what I said.



Because the way I understood what you described seemed to fit the way those function. Except the cursor-placement stuff seemed unnecessary. I thought you'd misunderstood which filter I was asking about, despite the fact that you called it the right thing.

I think I would've understood what you meant if, instead of...
[INDENT]"Input FX PlugIn chosen shows both pre and post patched FX"[/INDENT]

...you'd written:
[INDENT]"Input FX PlugIn chosen shows both pre and post patched individual plugin automation"[/INDENT]



Woah. I did not know that.



A couple things to say here. The "binding" rules are a little more broad. I find that the "bound" automation type is defined by the type at or closest prior to the cursor's location. I.e. ctrl-tab to--or place the cursor just after--your type of choice. Additionally, when making this cursor placement, you must be working in the current HotTrack--which is usually the case by virtue of how we typically work. A couple times, though, I was dragging in an adjacent track (inadvertently making it the HotTrack) when choosing my "key" automation entry, and when I selected the filter, it didn't work as I'd intended. I presume this requirement is not specific to this particular view filter.

Other thing to say: marked areas have no impact that I can see. I think you're just getting the normal behavior of the view filter: it's all determined by the "key" automation entry, which, as we've established, is up to the cursor and HotTrack.



RE: specific-channel graphics... I don't believe this is true. As with other filters, the view of all automation of that type across the MT are filtered.

RE: the three filter types doing the same thing in different places... beg to differ. The first two are limited to bypass state and work across all input channels at once. The last one can filter all available plugin automation and can be focused to a specific automation type for an individual plugin instantiation. This appears to be unique to this filter type.



You betcha.



Indeed. Thanks for the heads-up on that per-instantiation filtration thang!

Hold on. Now you got me thinkin' that you haven't even scratched the surface of individual(native)-plugin automation types. Say it ain't so! And sorry I haven't (apparently) extolled the virtues of said functionality sufficiently. Check this out (unless I'm an idiot and you're totally on-board with this already):

Load a Levelizer or a native Paragraphic EQ. Put a blank region somewhere down the timeline if ya gotta. Put the MT in Automation Mode. Hit the spacebar. Start moving knobs and stuff on that native plugin. Different knobs. Different stuff. Hit the spacebar.

Now move the cursor around and engage your new favorite view filter.

Hmmm, it's getting a bit tricky to keep track in posts with previous replies disappearing. Seems we are talking across each other a bit. As what is clear to one person is not clear to all and tricky to clarify using just text.

Yes, I see I was more focused on one input channel at a time and not across all tracks/ channels...just trying to understand the functionality...and as I try things out, I discover new things (i.e. Channel FX Patch cannot be automated until an effect is loaded)

I seldom use SAW native plugins (never, actually). I don't have Levelizer. Mixer channel automation I use/ edit all the time.

I just meant if user left-drag> then SS creates a marked area, not that the marked area has any bearing on setting the filter type.

Anyway, seems I've learned more than you have ;-P (cuz you already knew and I did not)

I best do some work!

[Dave Labrecque]

No, I learned a thing or two as well!

I thought you were saying that the marked area can be used somehow with the automation view filtering, though. No?

FWIW: the Native Echo/Delay and Paragraphic Equalizer plugins come with SS, no? If you ever want to play with (or utilize) automating different plugin parameters (and the relevant automation view filtering capabilities I blabbed about), those two would be there for ya.

You and me: poster children for RTFM.

[Todd R]

No, I learned a thing or two as well!

Yeah, but, you already know more than I :-) Glad I could help ;-P

I thought you were saying that the marked area can be used somehow with the automation view filtering, though. No?

no, I just meant users will typically make a marked area with left-drag in MT timeline
Creating a Marked Area is a by-product of that mouse move which user would/might naturally do when viewing the engage/ bypass states of the Input FX Plugin option is filtered
obviously various editing can be carried out with the Marked Area

FWIW: the Native Echo/Delay and Paragraphic Equalizer plugins come with SS, no? If you ever want to play with (or utilize) automating different plugin parameters (and the relevant automation view filtering capabilities I blabbed about), those two would be there for ya.

Yes, SAW Echo and PEQ I have and did test after you pointed that out :-)

You and me: poster children for RTFM.

I'd say poster children for help each make sense the FM. Unless the R stands for "Retain" in human brain =-D

[jmh]

marked area can be used somehow with the automation view filtering

Offset mode? ...but that's not what you were getting at.

You and me: poster children for RTFM

you, you, and me...

There's simply too much to retain. And I find these forum discussions essential to learning.

[Todd R]

The Input FX-Pre Sw and Input FX-Pre Sw are a native virtual mixer control

Obviously I copied and pasted, if we are attempting to be very clear (as I am), then best to not have any syntax mistakes

So "The Input FX-Pre Sw and Input FX-Pre Sw" is obviously the same thing, D'oh!

I meant:
The Input FX-Pre Sw and Input FX-Post Sw, phew

Ok, onto some other things which have occupied my thoughts re this conversation:

I've since figured out that the last item (on the right) is for automation specific to individual plugins patched on input channels.

Todd: all three are for that purpose.

I don't see how. The first two are not for individual plugins' automation but for patch module bypass states.

As I agree those two mixer channel parameters engage/ bypass the routing to each input channels' FX Patch (pre or post), I do consider it is all the same routing component (FX Section);
although each automation entry type (Input FX-Pre Sw or Input FX-Post Sw and Input FX Plugin) has different levels of control.

Well, obviously Input FX-Pre Sw or Input FX-Post Sw do the same one thing: flip a switch on or off and thus has a parental relationship to the Input FX Plugin.

The Input FX Plugin won't function if the Input FX-Pre Sw and Input FX-Post Sw switches are bypassed.
So what I intend to mean by "all three are for that purpose" I mean to say all three of those parameters control the FX section of an input channel.
They all have bearing upon each other. And, sure, you are probably thinking that is illogical, because all routing has reliance upon the flow of the routing.
For me, it's just easier to breakdown the various sections into groups and I'd say all three automation types relate to the same sub-section an input channel.

I think actually understanding the various functions of the Input FX Plugin is a black hole in the SAW User Manual, and that's where we started.
And between us have revealed to ourselves what the "special feature"s of the Input FX Plugin is :-)

[Dave Labrecque]

Todd, are you really in France? Polly voo frahnsay?