Control Surface Integration (CSI) Technical Feature Discussion

[Geoff Waddington]

Originally Posted by Funkybot

If there's no CSI folder at all, Reaper opens. Nothing else happens. No crash, no additional prompts or messages. At least, not on my Windows Portable Install.

If there's no CSI.ini file, same as above. If I go into my CSI preferences, there's no surfaces listed (as expected).

If there is a missing home.zon file or Zone folder, I get a pop up for each surface. If we have multiple surfaces, would it be possible to change the error message to just display a single prompt? If not, no worries, but would just save a few clicks.

Thanks for testing, I've never done a portable install, wonder why the GetResourcePath Reaper function finds the CSI stuff in its regular location, rather than searching the portable install resource path ?

As to combining the Zone file errors, don't think we want to do that -- I think we want to plainly point out what's missing -- it's not like you should hit this often -- I think "optimization" is counter productive in this case

[Puck]

I'm dumb, is this the osc color problem though? lol

2030  void OSC_FeedbackProcessor::SetRGBValue(int r, int g, int b)

Is this somehow informing the OSC message that these are to be integers?

I doubt that's it but I'm watching c++ tuts and trying to dig in.

This is likely just telling CSI they are integers, which they are, so no big deal. The problem is the OSC message type. But I found this looking through the code and figured I'd ask

[Geoff Waddington]

Originally Posted by Puck

I'm dumb, is this the osc color problem though? lol

2030  void OSC_FeedbackProcessor::SetRGBValue(int r, int g, int b)

Is this somehow informing the OSC message that these are to be integers?

I doubt that's it but I'm watching c++ tuts and trying to dig in.

This is likely just telling CSI they are integers, which they are, so no big deal. The problem is the OSC message type. But I found this looking through the code and figured I'd ask

Very cool that you are looking at the code !

What are you using to see it, just a text editor, or Xcode or Visual Studio.

If you look at the function body - aka contents -- you see that the r, g, and b, values get sent separately by calls to

SendOSCMessage(this, oscAddress_ + "/rColor", r);
SendOSCMessage(this, oscAddress_ + "/gColor", g);
SendOSCMessage(this, oscAddress_ + "/bColor", b);

If you then follow the bread crumbs you see this:

void OSC_ControlSurface::SendOSCMessage(OSC_FeedbackProcessor* feedbackProcessor, string oscAddress, int value)
{
    if(outSocket_ != nullptr && outSocket_->isOk())
    {
        oscpkt::Message message;
        message.init(oscAddress).pushInt64(value);
        packetWriter_.init().addMessage(message);
        outSocket_->sendPacket(packetWriter_.packetData(), packetWriter_.packetSize());
    }
}

Looks like it might be worth while changing the pushInt64 to pushInt32 and see what happens.

Can you compile and run code yet ?

If not maybe we can add a 32 bit version of void OSC_ControlSurface::SendOSCMessage(OSC_FeedbackPro cessor* feedbackProcessor, string oscAddress, int value) that sends the 32 bit version.

Real nice detective work !!

[Puck]

Originally Posted by Geoff Waddington

Very cool that you are looking at the code !

What are you using to see it, just a text editor, or Xcode or Visual Studio.

If you look at the function body - aka contents -- you see that the r, g, and b, values get sent separately by calls to

SendOSCMessage(this, oscAddress_ + "/rColor", r);
SendOSCMessage(this, oscAddress_ + "/gColor", g);
SendOSCMessage(this, oscAddress_ + "/bColor", b);

If you then follow the bread crumbs you see this:

void OSC_ControlSurface::SendOSCMessage(OSC_FeedbackProcessor* feedbackProcessor, string oscAddress, int value)
{
    if(outSocket_ != nullptr && outSocket_->isOk())
    {
        oscpkt::Message message;
        message.init(oscAddress).pushInt64(value);
        packetWriter_.init().addMessage(message);
        outSocket_->sendPacket(packetWriter_.packetData(), packetWriter_.packetSize());
    }
}

Looks like it might be worth while changing the pushInt64 to pushInt32 and see what happens.

Can you compile and run code yet ?

If not maybe we can add a 32 bit version of void OSC_ControlSurface::SendOSCMessage(OSC_FeedbackPro cessor* feedbackProcessor, string oscAddress, int value) that sends the 32 bit version.

Real nice detective work !!

Awesome

I was just looking at the source on GitHub. I haven't compiled anything yet but I'd say this is a helluva good reason to start. I also don't know how to 'follow the bread crumbs' just yet so I'm glad you did a little of that for me!

I'll give it a go.

edit: I see what you mean now, sort of. The SendOSCMessage is defined somewhere else and you showed me that. The file structure of all of this is unreal lol.

But anyhow, I've my mission. Shall report back.

edit 2: Wouldn't we pushFloat? That's what it was before. I get that they are integers though, maybe we try this pushInt32 fix and see I can get TouchOSC to respond to that.

....

edit 3: Weird, I've been saying this whole time 'INT64' isn't really part of the OSC spec. But this (I'm not sure what to call it, library?) that you've included, lists it pretty clearly, while making note above somewhere that int32, float, boolean, and string are the bare minimum. This is from oscpkt.hh

  Message &pushInt32(int32_t i) { return pushPod(TYPE_TAG_INT32, i); }
  Message &pushInt64(int64_t h) { return pushPod(TYPE_TAG_INT64, h); }
  Message &pushFloat(float f) { return pushPod(TYPE_TAG_FLOAT, f); }

So pushInt32 would work as you said, and like I was saying, it was float before. So it changed somewhere along the way.

I didn't get too far at all with the compiling though. I didn't realize xcode was a mac thing. I figured you having the project would be somewhat convenient and it definitely would have been had I have had a mac lying around

Researching whether you can open up those projects with VS or not but I plan on learning more about c++ so I'm sure I can figure it out just using all the files you have and VS.

[Geoff Waddington]

Originally Posted by Puck

Awesome

I was just looking at the source on GitHub. I haven't compiled anything yet but I'd say this is a helluva good reason to start. I also don't know how to 'follow the bread crumbs' just yet so I'm glad you did a little of that for me!

I'll give it a go.

edit: I see what you mean now, sort of. The SendOSCMessage is defined somewhere else and you showed me that. The file structure of all of this is unreal lol.

But anyhow, I've my mission. Shall report back.

edit 2: Wouldn't we pushFloat? That's what it was before. I get that they are integers though, maybe we try this pushInt32 fix and see I can get TouchOSC to respond to that.

....

edit 3: Weird, I've been saying this whole time 'INT64' isn't really part of the OSC spec. But this (I'm not sure what to call it, library?) that you've included, lists it pretty clearly, while making note above somewhere that int32, float, boolean, and string are the bare minimum. This is from oscpkt.hh

  Message &pushInt32(int32_t i) { return pushPod(TYPE_TAG_INT32, i); }
  Message &pushInt64(int64_t h) { return pushPod(TYPE_TAG_INT64, h); }
  Message &pushFloat(float f) { return pushPod(TYPE_TAG_FLOAT, f); }

So pushInt32 would work as you said, and like I was saying, it was float before. So it changed somewhere along the way.

I didn't get too far at all with the compiling though. I didn't realize xcode was a mac thing. I figured you having the project would be somewhat convenient and it definitely would have been had I have had a mac lying around

Researching whether you can open up those projects with VS or not but I plan on learning more about c++ so I'm sure I can figure it out just using all the files you have and VS.

Ah, got it now, I forgot it was float, not 1nt32 we were looking for.

The visual Studio project is also included, it's in the Windows folder, that's how CSI gets compiled for both platforms.

Remind me of your coding experience with languages other than C++.

[Geoff Waddington]

New build is up.

CSI Exp.zip

Possible fix for OSC colours.

Note that this also may break OSC for some, work remains, will tighten up as version 2.0 coding continues...

[MixMonkey]

Originally Posted by Geoff Waddington

New build is up.

CSI Exp.zip

Possible fix for OSC colours.

Note that this also may break OSC for some, work remains, will tighten up as version 2.0 coding continues...

OSC still working here Could you reinstate blanking displays set to NoAction? That would clean things up a lot

I noticed GoSubZone is in the Action list you posted, are SubZones good to go?

[Geoff Waddington]

Originally Posted by MixMonkey

OSC still working here Could you reinstate blanking displays set to NoAction? That would clean things up a lot

Yes, as noted there is a fair bit of OSC cleanup to do

Originally Posted by MixMonkey

I noticed GoSubZone is in the Action list you posted, are SubZones good to go?

Should work, give it a try and let us know

[MixMonkey]

Originally Posted by Geoff Waddington

Should work, give it a try and let us know

Gave it quick try before I have to go out, no luck i'm afraid. Here's what i'm using:

Zone "Home"
    OnInitialization PreventFocusedFXMapping
    OnInitialization Broadcast TrackSend TrackReceive TrackFXMenu Home
        IncludedZones
            "Buttons"
            "Track" "PanWidth"
            "MasterTrack"
        IncludedZonesEnd
        
        AssociatedZones
            "SelectedTrackSend"
            "SelectedTrackFXMenu"
            "SelectedTrackReceive"
            "TrackSend"
            "TrackReceive"
            "TrackFXMenu"
        AssociatedZonesEnd
ZoneEnd

Zone "Track"    
        DisplayUpper|                       TrackNameDisplay
        DisplayLower|                       TrackPanDisplay 
        Fader|Touch+DisplayLower|           TrackVolumeDisplay
        Alt+DisplayLower|                   TrackAutoModeDisplay
        RotaryPush|                         GoSubZonePanWidth
        Rotary|                             TrackPan "0"
        RecordArm|                          TrackRecordArm
        Solo|                               TrackSolo
        Mute|                               TrackMute
        Select|                             TrackUniqueSelect
        Shift+Select|                       TrackRangeSelect    
        Control+Select|                     TrackSelect
        Fader|                              TrackVolume
        VUMeter|                            TrackOutputMeter
ZoneEnd

Zone "PanWidth"
        DisplayLower|     TrackPanWidthDisplay 
        RotaryPush|       LeaveZone
        Rotary|           TrackPanWidth "1"
ZoneEnd

[Puck]

Originally Posted by Geoff Waddington

New build is up.

CSI Exp.zip

Possible fix for OSC colours.

Note that this also may break OSC for some, work remains, will tighten up as version 2.0 coding continues...

Perfect! They come in as float and work as before. Thanks a bunch!

....

As far as experience coding it's close to nothing, but not for lack of trying

I've learned enough to modify some ReaScripts, and now I've learned a very sandboxed version of LUA in TouchOSC. But things are starting to click. That's awesome there's a VS project as well! I'm still going to go through the motions and see if I can't compile it myself. Maybe a little bit down the line I can be of some use, lol.

Is the Github up to date?

[Funkybot]

Very cool that you're teaching yourself scripting and coding! Keep it going!

[Geoff Waddington]

Originally Posted by MixMonkey

Gave it quick try before I have to go out, no luck i'm afraid. Here's what i'm using:

Zone "Home"
    OnInitialization PreventFocusedFXMapping
    OnInitialization Broadcast TrackSend TrackReceive TrackFXMenu Home
        IncludedZones
            "Buttons"
            "Track" "PanWidth"
            "MasterTrack"
        IncludedZonesEnd
        
        AssociatedZones
            "SelectedTrackSend"
            "SelectedTrackFXMenu"
            "SelectedTrackReceive"
            "TrackSend"
            "TrackReceive"
            "TrackFXMenu"
        AssociatedZonesEnd
ZoneEnd

Zone "Track"    
        DisplayUpper|                       TrackNameDisplay
        DisplayLower|                       TrackPanDisplay 
        Fader|Touch+DisplayLower|           TrackVolumeDisplay
        Alt+DisplayLower|                   TrackAutoModeDisplay
        RotaryPush|                         GoSubZonePanWidth
        Rotary|                             TrackPan "0"
        RecordArm|                          TrackRecordArm
        Solo|                               TrackSolo
        Mute|                               TrackMute
        Select|                             TrackUniqueSelect
        Shift+Select|                       TrackRangeSelect    
        Control+Select|                     TrackSelect
        Fader|                              TrackVolume
        VUMeter|                            TrackOutputMeter
ZoneEnd

Zone "PanWidth"
        DisplayLower|     TrackPanWidthDisplay 
        RotaryPush|       LeaveZone
        Rotary|           TrackPanWidth "1"
ZoneEnd

You don't include SubZones, they go in the SubZones list of the enclosing Zone:

        IncludedZones
            "Buttons"
            "Track" "PanWidth"
            "MasterTrack"
        IncludedZonesEnd

Zone "Track"    
        DisplayUpper|                       TrackNameDisplay
        DisplayLower|                       TrackPanDisplay 
        Fader|Touch+DisplayLower|           TrackVolumeDisplay
        Alt+DisplayLower|                   TrackAutoModeDisplay
        RotaryPush|                         GoSubZonePanWidth
        Rotary|                             TrackPan "0"
        RecordArm|                          TrackRecordArm
        Solo|                               TrackSolo
        Mute|                               TrackMute
        Select|                             TrackUniqueSelect
        Shift+Select|                       TrackRangeSelect    
        Control+Select|                     TrackSelect
        Fader|                              TrackVolume
        VUMeter|                            TrackOutputMeter
        SubZones
            "PanWidth"
        SubZonesEnd
ZoneEnd

Unlike the Associated Zones, GoSubZone takes a parameter:

        RotaryPush|  GoSubZone "PanWidth"

Try that and see what happens.

[Geoff Waddington]

Originally Posted by Puck

Perfect! They come in as float and work as before. Thanks a bunch!

....

As far as experience coding it's close to nothing, but not for lack of trying

I've learned enough to modify some ReaScripts, and now I've learned a very sandboxed version of LUA in TouchOSC. But things are starting to click. That's awesome there's a VS project as well! I'm still going to go through the motions and see if I can't compile it myself. Maybe a little bit down the line I can be of some use, lol.

Is the Github up to date?

Yes, Github is always at least up to date, sometimes it even leads the latest build, if I am trying something out

As far as coding, man I admire your fearlessness, C++ can be pretty daunting compared to the other languages you mentioned

Glad the fix worked, take a look at the OSC_FeedbackProcessor::SetRGBValue(int r, int g, int b) member function and see if you can figure out what changed and why it now works

[Puck]

Originally Posted by Geoff Waddington

Yes, Github is always at least up to date, sometimes it even leads the latest build, if I am trying something out

As far as coding, man I admire your fearlessness, C++ can be pretty daunting compared to the other languages you mentioned

Glad the fix worked, take a look at the OSC_FeedbackProcessor::SetRGBValue(int r, int g, int b) member function and see if you can figure out what changed and why it now works

Ok so what I think you did is:

You changed the data type to double.

The way you have it set up, it looks like in the SendOSCMessage function, the last value you pass to it determines what gets sent out. Passing an integer like before caused it to be INT64, passing a string would send a string out, and passing it a double now calls the pushFloat. So you didn't even have to change 'pushINT64' to 'pushINT32'. Changing the data type going into the function was enough to send out OSC floats instead of INT64.

Lots about it I don't understand for sure but hopefully I'm on the right track!

[Geoff Waddington]

Originally Posted by Puck

Ok so what I think you did is:

You changed the data type to double.

The way you have it set up, it looks like in the SendOSCMessage function, the last value you pass to it determines what gets sent out. Passing an integer like before caused it to be INT64, passing a string would send a string out, and passing it a double now calls the pushFloat. So you didn't even have to change 'pushINT64' to 'pushINT32'. Changing the data type going into the function was enough to send out OSC floats instead of INT64.

Lots about it I don't understand for sure but hopefully I'm on the right track!

You are extremely close, great job !

C++, and many other languages have a concept called overloading.

Notice that there are many versions of the same function -- SendOSCMessage

The one with the int as the last parameter (line 2466 in my build) was being called before, but by coercing the int to a double, the one on line 2449 gets called instead, the compiler notices the (double) coercion, and says, aha, you want me to convert this int to a double and call that overload (the one that takes a double) of the function.

Then, on line 2454, that double gets coerced in to a float, voila !

Great that you get this, it is important -- you are well on your way !!

[Puck]

Originally Posted by Geoff Waddington

You are extremely close, great job !

C++, and many other languages have a concept called overloading.

Notice that there are many versions of the same function -- SendOSCMessage

The one with the int as the last parameter (line 2466 in my build) was being called before, but by coercing the int to a double, the one on line 2449 gets called instead, the compiler notices the (double) coercion, and says, aha, you want me to convert this int to a double and call that overload (the one that takes a double) of the function.

Then, on line 2454, that double gets coerced in to a float, voila !

Great that you get this, it is important -- you are well on your way !!

Awesome! I was actually thrown for a loop they were all the same function except for the last parameter. That’s how I deduced what I did but the way you describe it makes a lot of sense.

Thanks so much for explaining. That’s a really cool concept!

[Equitone]

Geoff gives its name in his post, but no link. I've paddled around on github, but can't find latest build there either.
Thanks for any help.

[Puck]

Originally Posted by Equitone

Geoff gives its name in his post, but no link. I've paddled around on github, but can't find latest build there either.
Thanks for any help.

Here ya go! He uploads the Experimental builds to the stash as well.

https://stash.reaper.fm/v/42044/CSI%20Exp.zip

[Equitone]

Thanks.

[MixMonkey]

Originally Posted by Geoff Waddington

Try that and see what happens.

Made the changes. Alas, still no go.

[Geoff Waddington]

Originally Posted by MixMonkey

Made the changes. Alas, still no go.

Thanks for testing !

The X Touch universal should be here by Monday or so, will dig into this then, when I will have a surface with working rotaries

[iNX]

Originally Posted by Geoff Waddington

Thanks for testing !

The X Touch universal should be here by Monday or so, will dig into this then, when I will have a surface with working rotaries

Maybe a start for color strip on the x Touch?

[d. gauss]

and MCP scroll follows selected track?

[Geoff Waddington]

Originally Posted by iNX

Maybe a start for color strip on the x Touch?

Yup, bug me about this again after we get the basic 2.0 functionality stabilized.

[MixMonkey]

Originally Posted by d. gauss

and MCP scroll follows selected track?

It already does.

Use this to turn it on or off at will:

SomeButton  ToggleScrollLink 1

It has feedback, so preferably use a button with an indicator.

[Geoff Waddington]

Originally Posted by d. gauss

and MCP scroll follows selected track?

Yup, bug me about this again after we get the basic 2.0 functionality stabilized.

[Geoff Waddington]

Originally Posted by MixMonkey

It already does.

Use this to turn it on or off at will:

SomeButton  ToggleScrollLink 1

It has feedback, so preferably use a button with an indicator.

I think he had a slightly different use case in mind, IIRC.

[MixMonkey]

Originally Posted by Geoff Waddington

I think he had a slightly different use case in mind, IIRC.

I see, ok

Regarding the control surface reset Action in Reaper, this seems to still work in OSC. Strange.

[Puck]

Originally Posted by MixMonkey

I see, ok

Regarding the control surface reset Action in Reaper, this seems to still work in OSC. Strange.

Nice find!

To add to it, I updated to the latest and resetting all surfaces still resets my OSC device.

[Geoff Waddington]

X-Touch universal arrived this morning, anyone got a set of Zones for it -- Home, Buttons, Track, MasterTrack, etc. ?

A set of MCU ones would do just fine.

A proper MCU.mst wouldn't hurt either.

In case you're wondering, I'm really lazy, I just code the stuff, I don't actually use it

On the serious side, my MCU Zones are a mess from using the Avid Mixes in MCU mode -- there is a LOT missing/different.

[Puck]

Originally Posted by Geoff Waddington

X-Touch universal arrived this morning, anyone got a set of Zones for it -- Home, Buttons, Track, MasterTrack, etc. ?

A set of MCU ones would do just fine.

A proper MCU.mst wouldn't hurt either.

In case you're wondering, I'm really lazy, I just code the stuff, I don't actually use it

On the serious side, my MCU Zones are a mess from using the Avid Mixes in MCU mode -- there is a LOT missing/different.

2 days early! WOOT!

[Funkybot]

Originally Posted by Geoff Waddington

X-Touch universal arrived this morning, anyone got a set of Zones for it -- Home, Buttons, Track, MasterTrack, etc. ?

A set of MCU ones would do just fine.

A proper MCU.mst wouldn't hurt either.

In case you're wondering, I'm really lazy, I just code the stuff, I don't actually use it

On the serious side, my MCU Zones are a mess from using the Avid Mixes in MCU mode -- there is a LOT missing/different.

Try the attached files. I haven't tested it, but based it off the CSI v1.1 files with updates for V2. There's some things that won't work: PanWidth zone, Zoom zone, but if I did it right, most things should work.

Use the stock mcu.mst, which should have everything. If MixMonkey posts a more thoroughly tested set of files, I'd say go with those, but this might be a good jumping off point in the meantime.

[mattrglenn]

Originally Posted by Geoff Waddington

X-Touch universal arrived this morning, anyone got a set of Zones for it -- Home, Buttons, Track, MasterTrack, etc. ?

A set of MCU ones would do just fine.

A proper MCU.mst wouldn't hurt either.

In case you're wondering, I'm really lazy, I just code the stuff, I don't actually use it

On the serious side, my MCU Zones are a mess from using the Avid Mixes in MCU mode -- there is a LOT missing/different.

Here you go! A bit unique to me, but the pieces are all there:
https://www.dropbox.com/t/oLdVJbzIAU9hFhtz

EDIT: The zones are mostly updated for v2, though there are some WIP projects.

[MixMonkey]

Originally Posted by Geoff Waddington

X-Touch universal arrived this morning, anyone got a set of Zones for it -- Home, Buttons, Track, MasterTrack, etc. ?

A set of MCU ones would do just fine.

A proper MCU.mst wouldn't hurt either.

In case you're wondering, I'm really lazy, I just code the stuff, I don't actually use it

On the serious side, my MCU Zones are a mess from using the Avid Mixes in MCU mode -- there is a LOT missing/different.

Sorry I'm a bit late to this party, been out all day It looks like you're pretty well covered, but here's my package anyway

[Geoff Waddington]

Thanks everyone, will incorporate these into my new setup

A nice bonus, the X-Touch universal has 2 actual USB ports on the back, so the SCE24 and Console 1 plug straight into the X-Touch, and only one USB port is used on the Mac Mini for the lot

[Geoff Waddington]

OK, this is going to be fun

Every button transmits both press and release.

Every button, except Rotary push and Fader touch, and I mean every button, even F1, F2, etc. lights up !!

I'm much more impressed than I thought I'd be with this thing

It clearly deserves its own .mst file to support all of these capabilities

Looks like I'll also be adding feedback to a lot more Actions

[Funkybot]

Originally Posted by Geoff Waddington

OK, this is going to be fun

Every button transmits both press and release.

Every button, except Rotary push and Fader touch, and I mean every button, even F1, F2, etc. lights up !!

I'm much more impressed than I thought I'd be with this thing

It clearly deserves its own .mst file to support all of these capabilities

Looks like I'll also be adding feedback to a lot more Actions

That would be great! I'm glad you're enjoying the unit. I don't own one, but it's the surface I try to steer people towards when they ask and what I'd buy if I were starting from scratch.

My X-Touch One zones make heavy use of...

Property+SomeButton   NoFeedback

...to get the lights off where they don't make sense (example: Markers), but it would be great if there was more feedback from CSI actions where it makes sense. Particularly if Zone feedback makes sense with the new architecture like having the Home button light up when in the Home Zone. I know MixMonkey uses DummyToggles to fake feedback for some things, so I'm sure he'd be appreciative too! Checking out his zones for the DummyToggles may even be a great place to identify some use cases for button feedback.

[MixMonkey]

Originally Posted by Funkybot

Particularly if Zone feedback makes sense with the new architecture like having the Home button light up when in the Home Zone. I know MixMonkey uses DummyToggles to fake feedback for some things, so I'm sure he'd be appreciative too! Checking out his zones for the DummyToggles may even be a great place to identify some use cases for button feedback.

Real Zone feedback to replace the dummy exclusive toggles would be great!

Edit: Just had a thought though, this might be more difficult than it initially looks because Zone navigation isn't really a "Toggle". I mean you have one Action to enter a Zone (GoSomeZone) and then another (LeaveZone/GoHome) to exit.

[MixMonkey]

Originally Posted by Geoff Waddington

It clearly deserves its own .mst file to support all of these capabilities

Here you go. Can't have the chef wasting his time doing the washing up

I added all the missing FB lines and corrected the rotary acceleration values.

[Geoff Waddington]

Originally Posted by MixMonkey

Real Zone feedback to replace the dummy exclusive toggles would be great!

Edit: Just had a thought though, this might be more difficult than it initially looks because Zone navigation isn't really a "Toggle". I mean you have one Action to enter a Zone (GoSomeZone) and then another (LeaveZone/GoHome) to exit.

Yup, I've come to the same conclusion.

We may be OK though, if we relax the constraints a bit.

Let's say we start at Home, we can light up whatever button you have assigned to GoHome.

Now let's say you press the GoSelectedTrackFX button, we can light that up, and since Associated Zones are exclusive, we can turn GoHome off.

As you say, it gets a bit more tricky if we GoSubZone PanWidth from Track, we are not strictly Home anymore, to which we can loosely reply "meh, we are mostly Home"

So, if we take the position that Home and the Associated Zones are "radio button" style, we can give some fairly good navigation information.

If we are willing to say our navigation is approximate -- if we have activated a SubZone (e.g. PanWidth) it doesn't really change things in terms of navigation information indication (for the nation, Jason -- sorry couldn't resist), I think we can make something workable, we'll have to try and see...