I suggest that the documentation on server types mention the possibility of setting up a server on a "cloud" provider such as AWS. This was suggested to me as a solution to a problem we had with two local ISPs that only communicated to the other's network via circuitous routes that introduced unacceptable latency. Using an AWS server provided acceptable latency for users of both of the ISPs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Bob - thanks for the suggestion. When you say "the documentation" what are you referring to exactly? There are unfortunately various possibiities. In the docs on the wiki, we use the term "server type" to describe the difference between private, public and central servers. How they are hosted (be it on AWS or any other cloud provider, at home, or on hardware in a data centre) is a separate issue that we leave to server operators.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Even the "Getting Started" doc doesn't say enough about the fact that all the clients in a session need to have a low-latency connection to a server. If no available server provides this, cloud hosting should be mentioned in Running a Server.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, in asking what are you referring to, I meant if you were referring to the docs on the wiki or not (there are lots of different places on the Internet where Jamulus documentation exists). I assume you mean the official Jamulus wiki.
Low latency for all clients is of course a desireable thing, but it's not the only factor that can influence the overall quality of a session (hardware/software at the client and server ends, whether clients/servers are using Wifi, running Zoom etc. etc. all come into it), so we don't want to flood people with information about all that when they're getting started, if only because for many people things may just work fine on first attempt. This is why we structure the wiki in that way with general info at first, and lead people to a Troubleshooting section later on.
As to mentioning cloud hosting in Running a Server, I've added a couple of points about that on the Running a Server page.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Low latency for all clients is of course a desireable thing,
No, it's an essential thing. The Getting Started document is currently oriented to an individual client. But Jamulus is intended to support collaboration and Getting Started should be oriented to the collaborating group. Whoever is choosing the server should be aware of that essential thing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you mean the Getting Started here? In which case, that's about the use of clients connecting to servers (public servers by default) which is the main Jamulus use case. Talking about the operation of servers on cloud hosts etc. would be plainly confusing on that page, since you do not need to run a server to use Jamulus and we don't want to create the impression that you should (in fact we suffer from having too many!)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Do you mean the Getting Started here? In which case, that's about the use of clients connecting to servers (public servers by default) which is the main Jamulus use case.
The key word here is clients; that is; more than one. A single client isn't going to be collaborating. The client group has to select a server and it should be emphasized that the selection has to provide good latency for all of them. I'm not suggesting that cloud hosting has to be suggested on Getting Started; just that that page has to cater to a client group, not to a single client by him/herself selecting a server.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it should be emphasized that the selection has to provide good latency for all of them.
The server list is sorted by ping time for that reason. We could emphasise that the lower the ping time of the server you choose, the more likely it is that you will have a better jam on it. But in a group context that's not very helpful because one player's short ping time might be another player's long one, as you know. There's little we (or server operators) can do about that any more than a restaurant can be equidistant to all their diners. But having a choice of servers is part of the reason for having public servers in the first place.
Which leads neatly on to ...
A single client isn't going to be collaborating.
This is an interesting point. When Volker created Jamulus about 15 years ago, he envisaged it primarily as a way of letting people jam togther for the purposes of tansient musical fun. Hence the name in fact. It's not "Groupulus" or "Rehearsalus". And the software's architecture reflects that vision. If you experience poor server performance, don't like what you're playing or who you're playing it with, you can just leave and choose another server with other people in it. Jamulus is open, anonymous and free.
But it may be that the spontaneous online jam is now not the main use case. Our user survey (150 responses over the last two months) shows that only about 20% of poeple say they mainly use it for jams with random strangers. 40% for rehearsals and about 25% for jams with friends.
How much of this is down to lockdown we don't know though (activity on the forums and in downloads has reduced a great deal since spiking in mid March). I might for this reason close the current "lockdown era" survey and start it again to see if the trend has changed.
I should point out that you are the fist person to make this suggestion about the docs though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But it may be that the spontaneous online jam is now not the main use case. Our user survey (150 responses over the last two months) shows that only about 20% of poeple say they mainly use it for jams with random strangers. 40% for rehearsals and about 25% for jams with friends.
And like dark matter not interacting with visible matter, every free software galaxy tends to be surrounded by lots of dark users adding to its weight without interacting with it. Rehearsals will prefer private servers, private installations, and chances are that you don't get a lot of feedback from those.
In particular, I expect that a user hopping through public servers and communicating with different groups has a certain chance to be answering surveys and communicating on the forums. But for those who have a closed server they do rehearsals on, the only one likely to be similarly visible is the one running the server and likely doing tech support for the other members of the group running Jamulus clients.
So my guess is that your 40% for rehearsals number is seriously underrepresenting the people using Jamulus for rehearsals.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I suggest that the documentation on server types mention the possibility of setting up a server on a "cloud" provider such as AWS. This was suggested to me as a solution to a problem we had with two local ISPs that only communicated to the other's network via circuitous routes that introduced unacceptable latency. Using an AWS server provided acceptable latency for users of both of the ISPs.
Hi Bob - thanks for the suggestion. When you say "the documentation" what are you referring to exactly? There are unfortunately various possibiities. In the docs on the wiki, we use the term "server type" to describe the difference between private, public and central servers. How they are hosted (be it on AWS or any other cloud provider, at home, or on hardware in a data centre) is a separate issue that we leave to server operators.
Even the "Getting Started" doc doesn't say enough about the fact that all the clients in a session need to have a low-latency connection to a server. If no available server provides this, cloud hosting should be mentioned in Running a Server.
Sorry, in asking what are you referring to, I meant if you were referring to the docs on the wiki or not (there are lots of different places on the Internet where Jamulus documentation exists). I assume you mean the official Jamulus wiki.
Low latency for all clients is of course a desireable thing, but it's not the only factor that can influence the overall quality of a session (hardware/software at the client and server ends, whether clients/servers are using Wifi, running Zoom etc. etc. all come into it), so we don't want to flood people with information about all that when they're getting started, if only because for many people things may just work fine on first attempt. This is why we structure the wiki in that way with general info at first, and lead people to a Troubleshooting section later on.
As to mentioning cloud hosting in Running a Server, I've added a couple of points about that on the Running a Server page.
No, it's an essential thing. The Getting Started document is currently oriented to an individual client. But Jamulus is intended to support collaboration and Getting Started should be oriented to the collaborating group. Whoever is choosing the server should be aware of that essential thing.
Do you mean the Getting Started here? In which case, that's about the use of clients connecting to servers (public servers by default) which is the main Jamulus use case. Talking about the operation of servers on cloud hosts etc. would be plainly confusing on that page, since you do not need to run a server to use Jamulus and we don't want to create the impression that you should (in fact we suffer from having too many!)
I've looked at the Running a Server page. Thank you for those new remarks.
The key word here is clients; that is; more than one. A single client isn't going to be collaborating. The client group has to select a server and it should be emphasized that the selection has to provide good latency for all of them. I'm not suggesting that cloud hosting has to be suggested on Getting Started; just that that page has to cater to a client group, not to a single client by him/herself selecting a server.
The server list is sorted by ping time for that reason. We could emphasise that the lower the ping time of the server you choose, the more likely it is that you will have a better jam on it. But in a group context that's not very helpful because one player's short ping time might be another player's long one, as you know. There's little we (or server operators) can do about that any more than a restaurant can be equidistant to all their diners. But having a choice of servers is part of the reason for having public servers in the first place.
Which leads neatly on to ...
This is an interesting point. When Volker created Jamulus about 15 years ago, he envisaged it primarily as a way of letting people jam togther for the purposes of tansient musical fun. Hence the name in fact. It's not "Groupulus" or "Rehearsalus". And the software's architecture reflects that vision. If you experience poor server performance, don't like what you're playing or who you're playing it with, you can just leave and choose another server with other people in it. Jamulus is open, anonymous and free.
But it may be that the spontaneous online jam is now not the main use case. Our user survey (150 responses over the last two months) shows that only about 20% of poeple say they mainly use it for jams with random strangers. 40% for rehearsals and about 25% for jams with friends.
How much of this is down to lockdown we don't know though (activity on the forums and in downloads has reduced a great deal since spiking in mid March). I might for this reason close the current "lockdown era" survey and start it again to see if the trend has changed.
I should point out that you are the fist person to make this suggestion about the docs though.
And like dark matter not interacting with visible matter, every free software galaxy tends to be surrounded by lots of dark users adding to its weight without interacting with it. Rehearsals will prefer private servers, private installations, and chances are that you don't get a lot of feedback from those.
In particular, I expect that a user hopping through public servers and communicating with different groups has a certain chance to be answering surveys and communicating on the forums. But for those who have a closed server they do rehearsals on, the only one likely to be similarly visible is the one running the server and likely doing tech support for the other members of the group running Jamulus clients.
So my guess is that your 40% for rehearsals number is seriously underrepresenting the people using Jamulus for rehearsals.