Feature request: Cache current configuration

[alinsavix]

First off, thanks for this! I've been using it for a while and it works great!

I have a feature request for you, though: It would be really great if the proxy could cache the various settings it's seen, and send everything in that cache to a newly connected client (how can you tell if it's new? ...good question. I guess if it requests /xinfo? Or maybe if something requests /prefs/name?)

Why would I ask for such a thing? Well, one of the mixers I'm currently wrangling is about 7000 miles away (which is possible at all because of this proxy!). That usually works just fine, but if I need to synchronize my local client to the mixer's current state, it ends up taking minutes, because the sync is done by querying a bunch of settings one at a time, with a full round-trip (~200ms) for each one. If the proxy could cache all that info and just dump it to the client after it connected, a full sync wouldn't be required.

Yes, this is an extremely niche use case. I 100% understand if you just laugh and close the issue. But it can't hurt to ask, right?

[bradisbell]

Actually, this issue has been on my mind for awhile! I have a similar problem when I go camping... plenty fast enough connection, but high latency, and connecting a new mixer takes a bit to synchronize.

When a new client connects and starts to nail all those parameters for synchronization, I assume that if I flood back a bunch of stuff it didn't ask for, it will happily accept them anyway. I have yet to test this theory, but I don't see why it wouldn't work.

What client software to you use?

[alinsavix]

Oh, huh, small world (as far as niche needs goes!)

The software I'm typically using is the X-Edit desktop client, though sometimes mixing station as well.

I assume that if I flood back a bunch of stuff it didn't ask for, it will happily accept them anyway

It will, because that's how other clients (beyond the one that you're making a change on) know when a change has been made -- the updated values get sent to everyone currently subscribed.

And in the case of the XR18, "subscribed" would seem to be "has sent a /xremotenfb command in the last 10 seconds".

So I think the heuristic ends up being something like "if we get a /xremotenfb command from an IP that we haven't seen that command from in minutes, dump the full config". Normally (according to the docs) the client has to send that command every 10 seconds to keep getting parameter updates, so you could actually say "if we haven't seen that command from an IP in 10 seconds", but I figure giving a few minutes of slack is probably reasonable.

Hmmmm. Maybe the right thing to do would be to have the proxy actually do the /xremotenfb every 10 seconds, so it can catch config changes when there aren't any clients connected to it, and then dump the cache to any client that does a /xremotenfb for the first time in, say, the last 5 minutes (as well as starting to relay the actual config changes, which the proxy would be in charge of if it was running a /xremotenfb every ~10s). Or something like that.

I guess one outstanding question is "which parameters to cache", but that might be as simple as "everything except /meters" and probably a few config load/store commands. I'll dig through the docs some and see if I can form an opinion there.