Automation of Same Colored Controls In Same Area Challenge

[Todd R]

OK, so where the MT Aut button right-click for all params pop-up doesn't really help is for the VST wrapper bypass automation
...unless I'm missing something :-)

[jmh]

One of the things I do is nudge a parameter of interest at the beginning of a track so when you hit v it goes right to it rather than hunt for it. I can delete it after viewing the correct parameter - or if it is something that I may use offset on, like gain after adding a plugin, I just leave it at the beginning.

I can't remember for sure, but I think if there is no entry to the left of a marked region and you offset, the edit happens at the first marked entry rather than the boundary. In any case, that is what's pressed in my memory, so it is how I approach it.


While were on the topic of parameters and memory (or the lack of it). Is there a keystroke that can zero the last parameter? It is funny sometimes one of you says something, or you'll be looking in the manual and you'll spot a cool feature and think you should remember it. After a while it happens too many times and - fog!

[Todd R]

One of the things I do is nudge a parameter of interest at the beginning of a track so when you hit v it goes right to it rather than hunt for it.

If I go searching, I'll usually write one event with which to set the filter and then delete said event after my filtered editing.
What brought me back here to comment about the VST wrapper bypass is that I had a need to have a fader automation
and the VST bypass at the exact same point in time; yellow fader event always takes visible priority IME.
It would be great to have a way to exclude certain parameter types.

I can delete it after viewing the correct parameter - or if it is something that I may use offset on, like gain after adding a plugin, I just leave it at the beginning.

I stopped using offsets about 10 years ago, I found it easy to get lost with them. I can certainly see using them over busy fader sections tho.

I can't remember for sure, but I think if there is no entry to the left of a marked region and you offset, the edit happens at the first marked entry rather than the boundary. In any case, that is what's pressed in my memory, so it is how I approach it.

"entry"? or event? (ah, geez, now I gotta go look at the manual to keep up with terminology....)

..."When writing offline automation, creating a Marked Area on the MultiTrack and adjusting any console control that writes automation will adjust the marked range to the new setting and reset
the old setting at the end of the range."
I have to say I never ever use this...and I probably should start

Ah, here we go: "Automation Entries"...so, you are right, entry it is :-) I do prefer the term event...the term "entry" also refers to certain regions in SAW, like the all important "Key Entry".

Consider this terminology:
"Selecting MT Entries_[Left-Clicking] on an MT Entry selects and highlights it. [Left-Dragging] across multiple entries
across multiple tracks selects all entries that lie within the dragged path, regardless of how fast you drag."

When doing so, the automation change entries/ events are treated differently depending upon their position in the MT and the functions engaged in which to edit these events.
Automation change entries/ events within MT Entry boundaries are contained within the entry and those automation events within boundaries retain their relative positioning within its parent MT Entry;
automation events outside of MT Entry boundaries (orphans) remain in their MT positions editing MT Entries in SELECT MODE by default; as long as user leaves those orphans outside of MT Entry bounds.
The "orphan" automation events/ entries outside of MT Entry boundaries are edited by application of Marked Area by default, yet user can set different functionality.

So using the terminology of "entry" for automation change events becomes a bit confusing when the term "entry" is applied to multiple components with differing dependancies in the MT.

So what options do users have for the orphan automation events in SELECT MODE?
Aha! Yep, covered in the manual and using the logical term "orphan":
"Include Orphan Automation
When this option is activated, automation entries that are not attached (within the boundaries of a
Region entry) that lie between the first and last selected entries will be included in the operation.
This setting can be saved with your preferences."

So, users need to set their desired MT behaviour for the orphans! I did not know that =-D
And where do users set that Include Orphan Automation option?
"Select Mode Options
[Right-Clicking] on the Select Mode button pops up the Select Mode menu options. Entry
selection group options as well other special functions can be found here."

I'm such a novice!!! I didn't know about that! OK, that's incredibly helpful. It is a little tricky dealing with orphans before the first MT Entry and after the last MT Entry.
I will be using this.

You are right, lots of functionality easily forgotten if not oft used.

While were on the topic of parameters and memory (or the lack of it). Is there a keystroke that can zero the last parameter? It is funny sometimes one of you says something, or you'll be looking in the manual and you'll spot a cool feature and think you should remember it. After a while it happens too many times and - fog!

I've been wondering this myself as well...I'll go have a look...

Without a control surface, I don't see any quicker way to pull mixer fader down than left-click drag at channel fader control.
I have been using the F-Mixer a lot lately and pulling faders down on F-Mixer is about half the throw distance as Z-Mixer or W-Mixer (I never use W-Mixer)

[jmh]

I'm such a novice!!!

I think we all are.

Without a control surface, I don't see any quicker way to pull mixer fader down than left-click drag at channel fader control.

There is number-selecting channels in mixer-view where you can manipulate several maintaining the relative differences.


Saw isn't on so I won't test it at the moment, just jotting down a thought - and this may not at all be applicable but maybe you can achieve your effects toggling with 2 number selected aux channels with one mute off and the other on. Do they toggle in the opposite directions? Of course if it does that, it would only work for however many spare return tracks. The other issue (since you want to move them around) is you would wind up with 2 automation events on top of each-other.

EDIT: Do they toggle in the opposite directions? I tried this last night and no, they all go to the state with the mute you clicked on.

[Todd R]

Right-Click on the AUT button and select an automation type and all other types are filtered out... so you can see just one type at a time if desired.

Bob L

[Todd R]

you would wind up with 2 automation events on top of each-other.

that's exactly the point of this thread...and even more than 2 automation events on the same layer; a multitude of automation events

[Todd R]

Right-Click on the AUT button and select an automation type and all other types are filtered out... so you can see just one type at a time if desired.

Bob L

Thanks, as Dave suggested as well; I have been using the Aut right-click pop-up a lot.

I don't find the VST wrapper engage/bypass in that pop-up which was yesterday's point. Possibly that switch resides somewhere else than all the native controls?
No worries, I learn a lot from these exchanges

[Dave Labrecque]

OK, so where the MT Aut button right-click for all params pop-up doesn't really help is for the VST wrapper bypass automation
...unless I'm missing something :-)

I'm not sure how he could code that since that filter type would address not-yet-existing instantiations. Of course, I'm not a code guy, and Bob's a genius, so...

Sidebar: the last filter type in the list is "Input Fx PlugIn." Anyone know what that may be referring to? :confused:

[Todd R]

Sidebar: the last filter type in the list is "Input Fx PlugIn." Anyone know what that may be referring to? :confused:

fx patch on an input channel
Input FX PlugIn chosen shows both pre and post patched FX
user can filter between pre and post by play cursor placement
to see both pre and post at the same time, filter has to be off, or
play cursor has to be placed before the first entry/ event

[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. I.e. RML-wrapper (non-native) plugin bypass or native plugin parameter automation.

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.

[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? :confused:

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? :confused:



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?