View Single Post
Old 02-12-2019, 04:33 AM   #2545
Geoff Waddington
Human being with feelings
Geoff Waddington's Avatar
Join Date: Mar 2009
Location: Dartmouth, Nova Scotia
Posts: 5,136

Usually don't quote myself, but sometimes it's instructive so here goes:

Zones -- designated area of a surface made up of a list of widgets -- Channel is a real world example of this that already exists.

Layers -- on the axt/fxt side, layers overlay the page definition -- FX mapping is a real world example of this that already exists, ditto for Modifier Keys -- Shift, Alt, etc.
That's a distinction without a difference.

There is a default definition for a surface
e.g. -- channels/tracks -- for MCU like
e.g. -- blank -- for C4, Console 1, etc. that are typically used for FX

Everything else is defined via Overlays.

In the case of a C4, the Overlay just maps an FX directly to the C4.
No need for navigation, very simple, it is done right now by the .fxt file definition.

OK, Overlay works for that, let's take it up a notch.

Let's say we want to navigate up and down the various FX for a track.

No problem, let's say we can have Overlay Stacks, just like stacks of pancakes.

We can go in and out of Overlay mode -- which really means we switch from default to current Overlay -- current Overlay means where we were in the pancake stack last time we were here -- say 3rd one down.

So we can now go from "normal" mode to the current FX Overlay (3rd one down)

We can navigate up and down the FX in Overlay mode.

Let's say we navigate to 1st FX Overlay.

Then we go back to normal mode.

When we go back to Overlay mode we will go from "normal" mode to the 1st FX Overlay, just where we left it

Now for drill down let's add the concept of sub Overlays.

Our navigation through the sub Overlays is remembered, exactly like our Overlay position is, so that when we return from normal, we come right back here

Extend that n levels deep in sub Overlays, and that is drill down...

OK, one more trick -- add navigation to Overlays -- whatever that means contextually for a given Overlay definition.

So, a bit more formal:
An Overlay describes a set of mappings of actions -> control surface widgets.
An Overlay can contain sub Overlays, n levels deep
An Overlay, or sub Overlay, can contain navigation, whatever that means in this Overlay's context

Overlays can be contained in a list called an Overlay Stack, you can navigate up and down this stack.

OK, last piece:

There can be many Overlay Stacks for a given surface definition (e.g. FX, Sends, etc.), but only one can be active at a time.

So the overall navigation is from "normal" mode to Overlay mode -- which means current Overlay Stack->current Overlay(sub Overlay, etc.)->currentNavigation within Overlay.

To me this seems to be organized more like we think, meaning more natural navigation, while still retaining the possibility of complex definitions.
What a load of crap

There are a finite number of controls on the surface.

The surface starts up in an initial configuration.

e.g. MCU
Usual suspects like Transport, function Keys, etc.
Track Navigation Zone

Whether it's a Send, FX, or whatever, it just the process of overlaying a Zone on top of the initial config temporarily.

So, when a Navigator becomes active, it overlays it's zone, simple as that.

Now, the current Zone in the Navigator can be whatever that means to that Navigator.

Don't think I'm missing anything, anyone else think of a reason we need the Overlay concept.
Beta software Donate
Installation / documentation / source

Last edited by Geoff Waddington; 02-12-2019 at 04:54 AM.
Geoff Waddington is offline   Reply With Quote