Make startup searching window indefinite

[brunchboy]

Currently when launching BLT, it will search for DJ Link devices for a fixed amount of time, and if none are found eventually presents the user with a dialog offering to Try Again, Quit, or Continue Offline.

A much better experience would be to have the window stay open for as long as it takes to find the DJ link network, but to have the Quit and Start Offline options available from the beginning (probably in the top right and top left corners of the window respectively). Not only would this allow users to decide whenever it is convenient to them (and avoid having to wait for a long time if they forgot to issue a command-line option when they wanted to operate offline), but it would support use cases like the Headless/VNC Raspberry Pi, because it would keep watching as long as necessary until CDJs were seen.

[brunchboy]

Once this is implemented, it would also make sense to go back into the Searching window automatically if BLT was online and then lost connectivity to all DJ Link devices.

[mattpstv]

I agree that the 'Try Again, Quit, Continue Offline' dialog is not ideal, but one benefit to the current setup is that it provides feedback about the state of the setup when the network is not setup properly. If BLT can't get online immediately and dialogue appears, I know that I need to make some physical adjustment (usually) to my network (eg. cat unplugged the 8 port hub). At the same time, I know (as a user) I'm 'in' the program and I just need to re-connecting to the network once I make a change (or set of changes). Basically, having the knowledge BLT is not connecting and then having to re-attempt a connection aids in troubleshooting, where as not having the knowledge that there's an issue with the connection until after user 'waits to see' seems to be less helpful when troubleshooting in the moment.

[brunchboy]

Good point, Matt. I will need to add a Troubleshooting button too. That way when the window isn’t going away you can hit that. Would that work for you?

[brunchboy]

It could just take you to the exact dialog that currently happens after the 30 second timeout.

[mattpstv]

I put a tiny little OLED on the RP4 in the hopes that I could design some clever visual feedback (at least for OBL) alerting user to whether they are connected or not, and if not connected, giving a simple option to re-attempt. And likewise for a network that goes down mid-use, it would be good to know if BLT was attempting a (forever) reconnection or if after X amount of time BLT would stop searching and give user a set of options as how to continue. Though for minor dropouts, the auto-watching/rejoin feature seems ideal.

[brunchboy]

Hmm, you might want to fork the code base then, because I need to support people who have no displays at all, and ensure that it will gradually converge on a working state if you plug in to some CDJs hours later.

[brunchboy]

Although with OBL, it already tries forever anyway! 😄

[mattpstv]

It also depends on how someone uses BLT. I always imagine walking into a situation/setup where BLT is almost being used as a diagnostic tool first, then if all checks out and connects, I can stop thinking about all the different ways the network could have been setup not correctly.

[brunchboy]

Maybe I could have the network troubleshooting information open up as a separate window if it has been trying for a long time, but leave the Quit and Start Offline buttons down in the Searching window. Then both windows would close when either you chose one of those options or the network was found…

[mattpstv]

The OLED is secondary really - it's a cool thing and an excuse for me to learn some stuff, but not necessary. But I have been wondering about the totally headless experience if there is no user feedback whtsoever. Obviously if it works, it works and it will be great. But what if someone disconnects something relating to the prolink network and other than watching your ableton link device drift from the pro link network, how could you tell there was an issue? (I don't have an answer or no this would really happen like this...)

[brunchboy]

Yes, for sure, truly headless is only workable on the happy path. If something goes wrong you’re going to need to ssh or VNC in and look at the state and log files. I like your idea of indicator lights too, maybe we can come up with some Came Online and Going Offline expression code that would use the GPIO pins to drive them.

[brunchboy]

@mattpstv if you would try the latest preview build, hopefully you will find that this new approach works well for you. It is now possible to cancel the attempt to go online at any point, rather than being forced to wait for many seconds for it to give up. You can either tell BLT to continue offline, or quit. And, as before, if it can’t find any DJ devices after trying for a long time, the searching window changes to a network troubleshooting window, but now it keeps trying to go online even while that window is up, and again, you can bail and continue offline or quit at any time.

[mattpstv]

I will try it today and report back. Perfect timing because I may need just this very solution for a thing in SF in a few weeks.

[brunchboy]

Cool! I also took a crack at making BLT automatically transition back to the searching-for-devices mode when it loses contact with the DJ Link network, so that it can recover and reconnect without user intervention over VNC when running on a headless Pi. I need to test that still, but you can perhaps help as well!

The new startup/connection flow is now documented and illustrated in the master branch of the User Gude.