"Virtual Distance"

[QJKX]

Where we see ping, have a toggle for "virtual distance".
So instead of 10ms it would show 3.43 meters (ie 10ms times the speed of sound, 343 m/s)
This should probably have the system latency added in as it's trying to convey a feel to the user, not raw technical information (which is better as a ping - because it means something in a networking context)..

The justification is that I think people have a better intuition for what it feels like to play with someone a certain physical distance away, than a certain time away, when the time is fairly low (1/2 a second is intuitive. 35ms is not.)
It's also a fun comparison that shows just how magic the software is.

[rdica]

The ping time displayed is to the server, not each individual player, so your justification makes no sense.

A server in NYC, a player in Toronto won't know what it feels like playing with another player from Washington DC thats also connected to that server as both are subject to their latency to the server, not each other. Network paths for each player to the server don't have any real world "distance" implications, especially in the cluster*** that is North American networks and routing.

Users can put their locations in their profile information if they so choose. Server operators (of which I am one) can also put location information in their server profiles that get sent to directory servers.

Are you confusing the client/server architecture of jamulus with a p2p architecture like sonobus, where your suggestion might make more sense?

Then there's the KISS principle as I understand the Jamulus devs like to follow...

[QJKX]

Are you confusing the client/server architecture of jamulus with a p2p architecture like sonobus, where your suggestion might make more sense?

I'm confusing it with quake which makes the ping time of every player available both in game, and in the server browser. You're right that Jamulus doesn't do that, which severely reduces the value of the idea (although knowing the upper limit of your experience still has value.)

A server in NYC, a player in Toronto won't know what it feels like playing with another player from Washington DC that's also connected to that server as both are subject to their latency to the server, not each other.

If you know the ping time of both players (and the various buffers/processing delays) you can work it out as a distance sound would travel in the same time - which is what it feels like.

especially in the cluster*** that is North American networks and routing.

:-(

[dcorson-ticino-com]

You are correct, Jamulus does not synchronise the streams, but through the merging it creates a fixed dephasing that all members hear the same. Thus synchronisation is possible through player actions. This possibility of synchronisation is not offered by the p2p architecture.
So if we don't use the word synchronisation, what word do we use?

[rdica]

Merge/mix?

[gene96817]

A consistent use of "mix" seems right to me.
Secondarily, we need to continue to emphasize the server does not provide synchronization.

[dcorson-ticino-com]

I would rather emphasize that the Jamulus architecture allows the players to synchronise, which the p2p architecture does not.

(I think this is important because I have been playing with groups across the Atlantic on both Jamkazam (p2p) and Jamulus recently. Jamkazam has half the ping time, but playing together is only possible for very slow and simple pieces as synchronisation is not possible. I have been very surprised myself at how well Jamulus has allowed us to play even with delays nearing 100ms. Of course it is the skill of the players making this work, but using Jamkazam the same players have not been able to get such good results even though the ping times are half as much. I think JK works fine if the ping times are small, but for playing across the Atlantic, for example, things start getting wierd, I have the feeling I am wading through mud, not really playing music. Everything swims. Gene do you have comparative experience ? I think you have one of the worst delay time situations I know.)

[gene96817]

I have played with Jamulus and JamKazam with musicians between New York and Boston. It is possible to play in sync if you listen to the remote musicians. I abandoned JamKazam for Jamulus because (1) there is more user support in P2P and (2) each P2P node affects performance far more than in a Jamulus (client-server) configuration.

Yes, I agree with @dcorson-ticino-com's experience. The most impactful observation for me is that the speed of sound in air is roughly 1 ms per foot. Performing on a (large) stage with 40ms is similar to a Jamulus experience. Stop thinking that the latency with Jamulus is so unique and different from in-person music! I take delight in seeing a musician from North America or Europe on an Asian server or someone in Asia on a North American server. Jamulus is awesome. My delay is only half as bad as the experience of a Taiwan musician visiting a North American server. LOL