Option to allow autoconnect to last server

[bugith]

Please add an option in settings or jamulus.ini to allow autoconnect to last server on client startup
Would be equivalent to cmd line jamulus -c <server>

Thanks for the great soft

[rdica]

You could always just type in the IP:port into the Connect dialog Server Address field at the bottom right , and as long as you don't delete your Jamulus.ini file, it'll always be there in the Server Address field history.

Or create a shortcut running your cmd line with specified server.

[bugith]

Hi @rdica
This FeatReq is not for me, I'm techy enough to tweak extra files or links to reach the goal. Instead it's for others/friends that are better at music than they are zeros in computers.

Maybe another way to approach better ergonomics would be a button on the main window (instead of an option checkbox "Connect to last server* on startup" in settings), called "Connect to last server" beside the "Connect" one but this would be less straightforward. Please understand how puzzeling it is to have to understand they have to launch Jack first, then Jamulus, then click "Connect" button then click another "Connect" button again... each time they want to use Jamulus.

For poor skilled users, having to tweak a shortcut is even more intimidating than a command line is because it requires the mandatory knowledge that the GUI of their OS is only an overlay of CLI that offers ease of use, and furthermore they'd need at least once a terminal to learn the parameters... if they ever have the idea to use the /? ... oh no, --help "universal" parameter, before falling in the $PATH or %PATH% trap, learn cd and separator character and if they succeeded in this, understand the -c option is what they looked for in the help output... when this info was not removed out of screen by the size of the window terminal FIFO memory... and they thought to use the scroller! If they didn't suicide or forgive ("OK, let's jam next time will meet in the real world, we'll have a real beer"), they're on the path. And sad thing, as this would be a one only time exercise, they wouldn't increase their knowledge in computers for other purposes. Whatever, using a new musical software is not intended to be a training for a better taming of computers OSes.
Do you remember your first days in computers ? Many people nowadays use computers for years but are as newb as they were on their first days with a keyboard when it comes to first basement of their OS.

For us more advanced users, when we want to help for specific software missing features in the GUI, we are required to write as many tutorial versions as compatible platforms exist, e.g. example screen-shots of how to tweak a Windows shortcut or create a Linux .desktop launcher or even write a script for the platform and teach users everything we hardly ended to learn... and forget every time we need it (e.g. chmod +x for linux scripts). When a single screen-shot (or great nice in-app help like Jamulus offers) from the very software would do the job.

There are two sorts of Jamulus users : first ones always use the same server. All others rather like roaming amongst servers. Humble devs would write the code for them... not for the third kind that are computers techies.
I know this is a terrific trade-off.

• When I asked for this feature I first though it could be universal and easy to code regards to the section in Jamulus.ini file. Although, after some tests it appears that:
  <client>
  <ipaddress0>a.b.c.d[:port]</ipaddress0>

is only updated from changes in the GUI "Server address" field in the bottom of "Connect" dialog (which would be enough for my/friends particular use case (private server). But it is not updated by the value of the command line -c parameter, nor it is by the selection a server in the list. So using ipaddress0 section would lead to a restrictive feature check box "Reconnect on startup" just beside the "Server Address" field.
I guess a feature with more universal scope (then labelled "Reconnect to last server on startup") would need a new dedicated section in Jamulus.ini updated by all 3 selection methods (-c, picked from list & typed address/name)... or have ipaddress0 updated by the 3 methods (after all, who cares with the sort order of entries in the drop list).

Do you guess? I'm not a dev although 30 years in computers.
Have a nice day

[rdica]

Sure, I understand that the history function of the Server Address field may not be entirely useful for you, or creating custom launchers in any OS may not be easy for some users.

Given the ephemeral nature of players gathering on published servers (the ones visible in the Connect dialog), I'm not seeing a use case for "Last connected server" though.

In my first year on the platform I never thought about the need for such a thing as players were rarely on the same server in any regularity. Based on behaviour I've seen over the last few years on EU servers there are a handful of "groups" that gather on specific servers, but even those players will often go from server to server as well. The server that one was last connected to may not be in use next time one starts their Jamulus client. The players that were on it may not be online, or connected to a different server.

In North/South America and Asia it looks like the player groups are a little more static in their server choices due to higher latency but still many roam from server to server.

No, I'm not a Jamulus developer, nor do I speak for them. It may well be that your request has merit and someone may put the work in to implement it. I presented alternatives in the case that the feature request is not accepted.

Cheers!

[ann0see]

What's your specific use case? Do you have a fixed group? I believe the problem lies elsewhere.

Are they clear that Jamulus uses public (registered) servers?

We had/have this setup and worked with a server configured as directory and entered the custom directory address in settings. All our users were OK with that.
Also: Why do they need to use JACK? If they are on Linux, you're probably using something like a Raspberry Pi -> build scripts to auto launch everything and deploy them to all devices.
If they're using Windows: use ASIO (not ASIO4ALL) and it should work ok.