Intelligent Metronome

[corrados]

This issue has been migrated from Sourceforge. Created: 2020-04-03 Creator: Petra-Kathi

An idea to minimize latency differences:

The server can detect latencies of individual clients by clock comparisons of respectively transmitted packets, so it should be able to advise the individual clients to create metronome ticks (not audible with the other participants) with individual latencies / time shifts of some (ten) milliseconds , so the strokes are heard with best relative timing.

The individual stroke timing should be derived from observation of the ping timing over the last, say, 5 seconds, so it would do some averaging against individual extraordinary retarded packets.

The participant with the slowest line should then get the stroke first, and the other ones appropriately retarded by some milliseconds. The result should be a better aligned combined sound, even though that would be retarded by about the amount of the latency of the slowest participant (single direction latency), but rather consistently.

[vocobox]

The idea is fun but would probably be a mess. Bad latency might maybe also unstable, meaning that your local metronome has a speed varying with the network latency. It also implies adding lot of sychronization information for this protocol to work instead of the current "best effort" mode of jamulus.

I personally like the approach of Jamulus described in Volker paper as following the "keep it simple principle".

Handling latency smartly is at the heart of Ninjam. I think this is good to have distinct software having distinct functions.

But it's just my opinion :)

[corrados]

I totally agree with you. I do not like the idea of having a metronome in Jamulus. If you need a metronome, something else is not configured correctly or you simply cannot jam in realtime because of some physical restriction (too far away from each other, your internet provider does not have low ping times, etc.).

[Petra-Kate]

The idea is fun but would probably be a mess. Bad latency might maybe also unstable, meaning that your local metronome has a speed varying with the network latency. It also implies adding lot of sychronization information for this protocol to work instead of the current "best effort" mode of jamulus.

The idea could be implemented in various levels of "intelligence":

1st level: Just implement an independent metronome ticker on the server as the central coordination point, and thus spreading a timing normal unconditionally as even as possible to every participant, and presumably split the average metronome latency by two, but by much more as far as the individual participants of a session are concerned. Especially so if they experience about the same individual latency relative to the server.

2nd level: Implement a short calibration phase, to be invoked willingly: measure average response times for a short period (like 3 s) based on individual member returns of pulsed test signals to each of them. Modify subsequent individual metronome transmits according to this (static) measurement to equalize expectable latency differences. Will not catch sudden quasi-permanent changes in network effects between calibration runs.

3rd level: Add a local, non-calibrated time stamp information to UDP packets sent to the server. Single precision integer (with overrun detection) would be completely satisfying, IMHO. Derive changing relative latencies from comparing their drift relative to each other (assumption: individual computer clock is sufficiently precise for the duration of a rehearsal). Do this on a several seconds averaging, so flatten out unmanageable jitter effects. Derive slightly deviating latencies and adjust relative metronome beats accordingly.

I personally like the approach of Jamulus described in Volker paper http://llcon.sourceforge.net/PerformingBandRehearsalsontheInternetWithJamulus.pdf as following the "keep it simple principle".

I agree completely to the KISS strategy but I wouldn't think that my suggestion violates it. I'd consider the increase in complexity for the suggestions above as quite small, compared to the compexity of the existing Jamulus as it is today.

Cheers,

Petra

[vanlaerav]

Hi, metronome is helping a lot! We use this..

The way we do is:

We add a member “clicky” who is running on a laptop in the same network as the server. Only the drummer is listening to “clicky” and we are trying to listen tintje drummer (it was allready hard in our rehearsal studio 😂). It works fine, except for the drummer, it is some times really difficult. But it prevents us to slow down during the song.

What a really great program Jamulus is!!! We use it during Corona for one month, it is really fun and works!!!

[Petra-Kate]

Hi, metronome is helping a lot! We use this..

We add a member “clicky” who is running on a laptop in the same network as the server.

This is about the method we use presently as well, since one of us (me) ist typically in the same network as the server. I use a smartphone metronome lying on the keyboard. But if we are more spread (begining next week) this method will double the latency, hence my suggestion.

I should mention, perhaps, that we try to organize classical music over Jamulus, therefore no such leading person with us usually, and quite some pauses that tend to pull us slow, since at the end of the pauses each is trying to listen to the others.

Cheers,

Petra

[vanlaerav]

The metronome is helping us for rock songs above 110

We decease in tempo... but with the version 3.5 and behringer IO we manage to keep the delay under the 29ms. And we live in Hilversum, Loosdrecht, Ankeveen around 10 kilometer apart..

So only the drum, is maintain the tempo...

[corrados]

With my band we can play rock songs with tempos like 170. We all only hear our own signal which comes back from the server. That way we keep in sync. The thing which kills the synchronization is if players have a pretty high latency and do direct monitoring instead of listening to their own signal coming back from the server. If I enter a Jamulus server and play with people, I instantly feel if they have setup their hardware properly and then we play tight together. If people listen to their direct signal, you instantly start to hear that they do not play tight to what you play and it actually does not make fun playing together. This is my personal experience.

[mirabilos]

If you need a metronome, something else is not configured correctly or you simply cannot jam in realtime because of some physical restriction

This is not entirely correct. A metronome also helps participants to stay on tempo, because otherwise, the listen to each other and thus the slight, almost non-noticeable delay adds up to something really noticeable. (I haven’t yet used Jamulus, working on a proper Debian package for it first, but the person who recommended it to me on the OSAMC mailing list noted that in her tests of it.)

[trebmuh]

As a musician, you never ever need a metronome to rehearse or to play within a band. The metronome is useful for practicing your instrument alone.

As a music teacher, I always tells my student to use it when they practice but never when they play in a band. What you need when playing in a band is to listen to the other musicians you're playing a song with, and not to listen to a little plastic and electronic who knows nothing about music. In other words, using a metronome in a band is just killing the musicality. Mostly because it's annoying for people who don't need it (audio pollution), and the people who think they need it, needs in fact to listen to other musicians (and to work their instrument at home, even maybe with a metronome).

Not to mention that it'll not cope with any of the songs you'll play which need tempo variation (even if slight BPM variations to enlight and strengthen small mood change in a song).

Having a metronome on jamulus is a good recipe for a musical experience disaster in my opinion.

[...] for rock songs [...] So only the drum, is maintain[ing] the tempo...

That is pretty much how any rock band is functioning all over the world :wink:

[Petra-Kate]

..., and the people who think they need it, needs in fact to listen to other musicians

This is exactly what should be avoided while using Jamulus: As I stated already before, and some others in here confirmed, listening to the fellow musicians will inadvertently lead to a slow-down due to the always present latency. As it is small, you think you can orient yourself by listening to your fellow musicians, but you can't.

This is even more so if there are some pauses in your voice - which may be rather seldom in rock/pop but is quite frequent in classic music. In addition, with most classic pieces there ain't such a thing as a drummer. :-) (Okay, there are exceptions like Bolero, but I would like to play some other pieces as well ...)

Cheers,

Petra

[vocobox]

1st level: Just implement an independent metronome ticker on the server as the central coordination point, and thus spreading a timing normal unconditionally as even as possible to every participant, and presumably split the average metronome latency by two, but by much more as far as the individual participants of a session are concerned.

@Petra-Kate I don't understand what you mean by "split the average metronome latency by two". We are enslaved by latency, we do not have control on it. Could you clarify that point?

listening to the fellow musicians will inadvertently lead to a slow-down due to the always present latency. As it is small, you think you can orient yourself by listening to your fellow musicians, but you can't.

👍 very interesting. How would you estimate this theoretically? I guess my below reasoning is wrong. Would you be able to make something accurate?

Assume the worst bandmate latency is L - expressed in millisecond, the speed is S in BPM, and the duration is D minutes. Is this right to estimate the song will be stretch by LxSxD milliseconds? With this reasonning, a 3 minutes song at 60 BPM with a 30 ms latency would last 5.4 more seconds.

[Petra-Kate]

1st level: Just implement an independent metronome ticker on the server
as the central coordination point, and thus spreading a timing normal
unconditionally as even as possible to every participant, and presumably
split the average metronome latency by two, but by much more as far as
the individual participants of a session are concerned.

@Petra-Kate https://github.com/Petra-Kate I don't understand what you mean by "split the average metronome latency by two". We are enslaved by latency, we do not have control on it. Could you clarify that point?

For the calculations I just assume some numbers: Average latency 50 ms, jitter 5 ms (playing across Germany, with someone situated in a "retarded" area :-))

If the person with a 50 ms latency is providing the metronome it will arrive at the others players 100 ms later (due to backward latency of 50 ms and then 50 ms forward latency again. In addition the jitter will increase, once again due to double passes, to averaged probably 7.5 ms

If we have an autonomous metronome at the server it will send its strokes independently, so they will arrive with the players about 50 ms later (depending on the individual latencies, of course), but with all players delayed mostly similiar. So the span of latency is split roughly by half. Jitter will be the one experienced by any player individually as well, so it remains the old value.

listening to the fellow musicians will inadvertently lead to a
slow-down due to the
always present latency. As it is small, you /think/ you can orient
yourself by listening to your fellow musicians, but you can't.

👍 very interesting. How would you estimate this theoretically? I guess my below reasoning is wrong. Would you be able to make something accurate?

Assume the worst bandmate latency is L - expressed in millisecond, the speed is S in BPM, and the duration is D minutes. Is this right to estimate the song will be stretch by LxSxD milliseconds? With this reasonning, a 3 minutes song at 60 BPM with a 30 ms latency would last 5.4 more seconds.

I'd like to reason on the basis of relative deceleration:

Let's assume we have 120 BPM, hence 2 beats per second (PBS). If each beat is delayed by 30 ms we have a retardation of 60 ms every second, or roughly 1/20 of the present speed. The effect will decrease over time since the number of beats per unit time will decrease, but nevertheless speed is constantly slowing down. I'm too lazy to do an exact mathematical calculation right now, but you will arrive at a (near-to) stand-still very soon: After about half a score sheet you will arrive at approximately half the original tempo. And this is excactly what we were observing when trying to listen to each other as we are used to from live playing.

Of course this is not practically correct as every musician will listen at least partially to his/her inner metronome, but the more you tend to listen to your fellows the stronger this effect is.

(Btw.: I guess this is one of the principal duties of the conductor during the concerto: to define an optical lead to the orchestra by his stroking. Luckily the velocity of light is slightly larger than that of sound. :-) Mind the fact that we have a delay of 3 ms/m in a live performance, so for large orchestras with distances of 20 - 30 m between left-most and right-most player this should play some role already, at least for really fast passages.)

Cheers,

Petra

[trebmuh]

This is exactly what should be avoided while using Jamulus: As I stated already before, and some others in here confirmed, listening to the fellow musicians will inadvertently lead to a slow-down due to the always present latency. As it is small, you think you can orient yourself by listening to your fellow musicians, but you can't.

Then one is not using the right tools and/or it's misconfigured. If in a band playing configuration one musician have to stop listening to other musicians, then it's a fail. Playing in a band is about listening to other.

This is even more so if there are some pauses in your voice - which may be rather seldom in rock/pop but is quite frequent in classic music. In addition, with most classic pieces there ain't such a thing as a drummer. :-) (Okay, there are exceptions like Bolero, but I would like to play some other pieces as well ...)

Yes, that is right, there is not a drummer in classical music, but there is a "conductor"... and we were talking about a rock band here. Moreover, you're giving me an example to proove my point even more with this example, in classic, they is more musicians and the music is even harder to play. And guess what ? Nobody is listening to a metronome :wink:

[mirabilos]

Olivier Humbert dixit:

in classic, they is more musicians and the music is even harder to play. And guess what ? Nobody is listening to a metronome

Because one can see the conductor there, with virtually no latency.

A server-generated metronome (Petra’s #1) would be the minimum and very useful. People will be using this far beyond the “Jam session” initial usecase. (I’d also think it might do for voice conferences; ofc no need for a metronome there, but this proves my point.)

Also consider amateur musicians, who need this to stay somewhat in sync.

[trebmuh]

Because one can see the conductor there, with virtually no latency.

Yes, and a conductor is a human connected to the music, a metronome isn't.

Also consider amateur musicians, who need this to stay somewhat in sync.

It has nothing to do with "amator" VS "professionnal" (or whatever). It has to do with playing as a musician or being training yourself. If you are training yourself, yes, you need a metronome.

If you're playing with other musicians and as a musician yourself, then the last thing you want is to have your attention focused on a clic-clic machine rather than the other musicians you're playing with. If there is too much latency for that to happen, bad luck you can't really play music with other musicians.

[mirabilos]

Olivier Humbert dixit:

Because one can see the conductor there, with virtually no latency.

Yes, and a conductor is a human connected to the music, a metronome isn't.

From the experiment the person who recommended Jamulus to me, the metronome is still better than no synchronisation that isn’t susceptible to the delay or lag inherent in distributed systems.

And ideally, the conductor has server access so can control the metronome.

[trebmuh]

I'm still on the "Having a metronome on jamulus is a good recipe for a musical experience disaster in my opinion" point of view which is a musician one.

But hey, if you convince the dev' to do so, as long as it's not mandatory to use it, I don't care.

That is just not "playing as a musician in a band".

[vocobox]

I'd like to reason on the basis of relative deceleration:

If I understand you well this is would be true if the drummer tries to catch up the band by slowing down a little, and then the band catch up the drummer by slowing down a little again.

I think it is better to

• have software developers working on improving latency and documenting how to minimize it with a good hardware/audio/network setup.
• have one reference musician in the band - preferably the drummer - equiped with a standard metronome on his/her side only to avoid small drift.

[mirabilos]

Vocobox dixit:

• have one reference musician in the band - preferably the drummer -
• equiped with a standard metronome on his/her side only to avoid small
• drift.

1. Our choir has no drummer.

2. This would still suffer from double latency, as opposed to a server-generated metronome.

[writemusic]

I'm in a vocal group, we are all on lowest jamulus latency option (64 samples) but it's somewhat hard and tempo tends to slow down.

What if the metronome sound was generated in the jamulus client, but the server makes sure the timing is synced? The click sound is never streamed as audio, but triggered locally for each participant.

I googled and found a Princeton University dissertation on this subject: Tools and Techniques for Rhythmic Synchronization in Networked Musical Performance (Full text PDF available). And I found The Global Metronome: Absolute tempo sync for networked musical performance (full text available there as well, and I also discovered that someone built a Rasberry Pi implementation on that one).

I'm not enough technically skilled to understand if it would be even possible to implement such a thing in Jamulus, but I do believe it would be useful to have a server synced metronome.

[mirabilos]

writemusic dixit:

What if the metronome sound was generated in the jamulus client, but the server makes sure the timing is synced? The click sound is never streamed as audio, but triggered locally for each participant.

Oh, that would circumvent the problem of needing to hear the sound before it could be sent. Interesting idea.

[Petra-Kate]

What if the metronome sound was generated in the jamulus client, but the server makes sure the timing is synced? The click sound is never streamed as audio, but triggered locally for each participant.

Oh, that would circumvent the problem of needing to hear the sound before it could be sent. Interesting idea.

A negative shift is no real problem for a metronome, as there is no information in the individual beat (contrary to the real music). It can be sent in advance, just relating to the timings of the preceding beats.

Petra

[jujudusud]

My opinion : Jamulus must be used with a latency of less than 30ms, it is written in the manual. If you are above this latency, then use another tool. :-)

[writemusic]

Jamulus must be used with a latency of less than 30ms, it is written in the manual. If you are above this latency, then use another tool. :-)

If you @jujudusud are referring to my post where I wrote about 64 samples (buffer size), that is the equivalent of the lowest latency option in Jamulus, resulting in approximately 2.67 ms latency. But even with that low latency it turns out that it can be hard for a group of singers to keep up the tempo with each other. Ping Time to server is just a few ms.

The "Overall Delay" has been around 40 ms though. I need to read up on this a bit more and see what can be done. But I would think many people trying to use Jamulus don't have the optimal equipment and would benefit from a globally synced metronome.

[mirabilos]

writemusic dixit:

The "Overall Delay" has been around 40 ms though. I need to read up on this a bit more and see what can be done. But I would think many people

Not much, if you’ve got a German ISP…

[jujudusud]

' If you @jujudusud are referring to my post where I wrote about 64 samples (buffer size), that is ' I just read the manual and corrados saying use a server under 30ms.

If you think you need a metronome in jamulus and someone writes the code, the only thing to keep in mind is that it has to be disengageable if you are in the case where a drummer sets the tempo.

[asakaplan]

There's an odd but of gatekeeping in the comments here, but I am going to reiterate that I think this would be a useful option. As others have said, latencies stack over time, so even <30ms will have a very small slow down over the course of the song. I've told everyone who's tried Jamulus that they're going to need a click track.

I actually started mocking up a separate server/client to do this before checking here, and the clock synchronization mentioned before by writemusic is exactly how I believe it should be done. Effectively, you need the server to get everyone to have the same clock, and then extremely roughly speaking you never need to modify it afterwards. Once everyone has the same clock, a bpm is communicated to everyone, and then there is common metronome logic on the clients to make sure everyone is aligned. (Plus some care to make new bpms be propagated in sync.)

There's some chance I could help with the effort, but unlikely admittedly.

[corrados]

It seems there are external tools available to fulfill the task, see, e.g.: http://www.shared-metronome.com So there is no need to integrate it into Jamulus.

[Petra-Kate]

It seems there are external tools available to fulfill the task, see, e.g.: http://www.shared-metronome.com So there is no need to integrate it into Jamulus.

Interesting, indeed!

Question remains who is behind the public metronome, and what will be done with the email adress after submitting?

Hint to prospective customer for Thomann? :-)

Cheers,

Petra

[corrados]

Question remains who is behind the public metronome, and what will be done with the email adress after submitting?

The same question I asked myself :-). Therefore I wrote "e.g." ;-). But I think what is important is that there exist tools for that which is very interesting.

[writemusic]

It seems there are external tools available to fulfill the task, see, e.g.: http://www.shared-metronome.com So there is no need to integrate it into Jamulus.

Unfortunately it turns out this metronome doesn't work - it's not a synced metronome. I opened it in two computers next to each other on the same network, the audio click is completely out of sync. Maybe there are others though...

[WolfganP]

I think that one of the main assumptions of the discussion is that the metronome will be in sync at all peer points not matter what, and clearly the current experience with the audio mix at the client side shows that it varies with network congestion, but the musician abilities of each performer compensates it while perceived delay is within certain limits.

Probably worthy to run a test with a client installed on the same machine as the server and just distributing metronome's audio (minimal upload jitter involved due colocation) and see it how it works (no need to develope anything new).

BTW, interesting paper on a global metronome sync http://www.doc.gold.ac.uk/~mas01rf/publications/OdaFiebrink_NIME2016.pdf but I don't know if something similar is implemented somewhere outside of the paper RasPi+GPS solution, or maybe something NTP based.

[bugith]

If something like a metronome is ever implemented in Jamulus, just a note not to forget for those who don't like audible click : a visual signal instead (big strobe flash in the GUI or floating window). This is closer to a conductor (although not human and won't do anything against latency itself)

[chigkim]

I also like to have click on Jamulus. Regardless whether it's good or bad, playing with click is widely used practice all over the world especially for drummer even during live shows. It's just a fact, and I think it's a good skill to have. Besides, Jamulus can implement so users can turn on/off the click if you don't like it. Also, here's an interesting paper from Princeton University to implement global metronom using gps clock. https://www.nime.org/proceedings/2016/nime2016_paper0006.pdf Or, use closest ntp server to sync time, and server to tell client to start generating click at what time?

[corrados]

The solution is that someone implements something like "http://www.shared-metronome.com" but so that it actually works :-).

[chigkim]

Awesome, can we implement similar thing to Jamulus for people to utilize? Otherwise, it's just another thing for people to download and setup.

[WolfganP]

Awesome, can we implement similar thing to Jamulus for people to utilize? Otherwise, it's just another thing for people to download and setup.

Just to check if it works for your band, did you run a metronome test by launching a 2nd client as suggested in https://github.com/corrados/jamulus/issues/79#issuecomment-644791661 ?

[chigkim]

a visual signal instead (big strobe flash in the GUI or floating window).

There should be definitely an option for visual, audible, or both. Visual flash can trigger seizures for people with Photosensitive epilepsy. https://webaim.org/articles/seizure/ Also, there are visually impaired users who can't utilize visual metronome.

[chigkim]

Just to check if it works for your band, did you run a metronome test by launching a 2nd client as suggested in #79 (comment) ?

If you just distribute the click to other clients from the client running on the same machine as the server, WOULDN'T different clients receive the click on different times?

Also I tried shared-metronome.com with 2 macs, 2 iphones, and 1 windows machines), 2 Macs and 2 iPhones were in sync, but my Windows machine was out of sync. I tried to update the time for the windows machine with time.apple.com, but but it was still out of sync. I'm not sure what's going on.

[WolfganP]

Just to check if it works for your band, did you run a metronome test by launching a 2nd client as suggested in #79 (comment) ?

If you just distribute the click to other clients from the client running on the same machine as the server, WOULDN'T different clients receive the click on different times?

That will always happen, is the nature of how Jamulus work...

[chigkim]

That will always happen, is the nature of how Jamulus work...

So it's better for Jamulus to implement each client to generate its own click based on the synchronized start time and interval. That seems how shared-metronome.com works.

[chrisrimple]

A click sent by the server to all clients could be beneficials for choral groups that are attempting to sing via Jamulus but struggling to stay in time. But I don't think it would be useful for a band, because the drummer will hear it and play, then the drummer's sound will go to the server and back to other musicians but likely not in sync with the server click. What we do instead is have the drummer play with a visual metronome, that no one hears, to help keep in time.

[mirabilos]

chrisrimple dixit:

A click sent by the server to all clients could be beneficials for choral groups that are attempting to sing via Jamulus but struggling to

Right, that would be my use case.

Thanks, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.” -- Edward Burr

[paulsijben]

just have gotten my acapella sextet on Jamulus. Next week we are going to rehearse for real (some people realize they want a better interface). We also realize we need a metronome. Having read up with this thread, I will try and get a "clicky" client on the server, with a simple BPM control. This allows the participants to change the volume in the jamulus interface.

[msf-git]

This issue seems to have deviated a bit from the original idea, which was to compensate the effect of each individual latency of the metronome tick arriving from the server by creating the tick on the client side.

to advise the individual clients to create metronome ticks (not audible with the other participants) with individual latencies / time shifts of some (ten) milliseconds , so the strokes are heard with best relative timing.

It has been stated above that it might be messy to co-ordinate this from the jamulus server because that means the server needs to send ticks to each client with appropriate advance to compensate for the (expected) delay to the client.

Here is a different way to solve this

Instead of sending ticks to the clients, the server only tells the clients when to tick in form of (future) timestamps (UTC). Each client creates the tick locally at the given time with respect to the system clock.

Rationale

Each participant hears the tick at the very same time. Rhythmic alignment is maximized at the time of sound creation by the musician. Because the tick is produced locally by the client at exactly the right time, no latency is involved. The musicians hear each other for pitch, voice, dynamic alignment etc. as usual. And they can still observe different timings due to different latency to and from the server. But the problem of getting slower and slower because each musician reacts to what is heard from the others can be overcome this way.

Clock synchronization

Getting the system clock synchronized to world-standard atomic clocks within a few milliseconds of Coordinated Universal Time (UTC) is the job of computer clock synchronization protocols. It is mastered by the Network Time Protocol and other solutions available on every computer. These are optimized to the client platform and share the advantage that they have a local clock and plenty of time. The system clock time and frequency are adjusted regularly to increase precision as much as possible and using statistical principles which continue to work under changing network conditions (read more). This (difficult) task has already been solved and can be made use of to prevent complexity in jamulus.

[gene96817]

@msf-git What problem are we trying to solve? Your ideas are a good start if we want to create a recording with the time skew between musicians removed. For instance, if you assume each musician's station has an accurate UTC (which is very hard), then the server can instruct each station to start the metronome at the same time. Now each musician can perform to the same metronome. If we put some metadata in the sound to represent the metronome, then the server can match up each musician's time skew and create a mix with every track deskewed. Note in this process, the musician cannot enjoy the combined sound until the server is finished with time alignment.

I see our problem as equivalent to a large orchestra or chorus in a concert hall. Each musician can choose to perform by closely watching the director (equivalent to the metronome) or the musician can use their ears. Depending on the musician's position on stage, they can experience different sound delays. An experienced orchestra/chorus performing can produce a quality performance by watching the director. Musicians who perform by ear will be late and out of sync.

Having a metronome is useful to keep the tempo from slowing down if the members listen to the group. I don't think we can do much more than that.

[paulsijben]

The problem I think we are trying to solve here, is the drift that is hitting acapella singers the hardest. They are used to listing to each other for their cue rather than looking at a conductor and will therefore be easiest to be delayed. So a delay-corrected metronome would benefit them most. If you have covered that usecase, you are (I believe) good enough for the other use cases

[WolfganP]

The problem I think we are trying to solve here, is the drift that is hitting acapella singers the hardest. They are used to listing to each other for their cue rather than looking at a conductor and will therefore be easiest to be delayed. So a delay-corrected metronome would benefit them most. If you have covered that usecase, you are (I believe) good enough for the other use cases

There's no way to correct the latency and delays inherent to the links to the clients (all data transport is done 'at best effort'), so adding a metronome at the server level won't be universally synched. The easiest way to test it is to add a client on the same machine as the server (minimum latency and drift) injecting a metronome signal. Did you try that already?

[writemusic]

There's no way to correct the latency and delays inherent to the links to the clients (all data transport is done 'at best effort'), so adding a metronome at the server level won't be universally synched.

Are you sure? I believe these papers beg to differ (copied from this reply in the discussion thread):

• Tools and Techniques for Rhythmic Synchronization in Networked Musical Performance (Full text PDF available).
• The Global Metronome: Absolute tempo sync for networked musical performance (full text available there as well, and I also discovered that someone built a Rasberry Pi implementation on that one).

But I don't know how realistic/unrealistic it would be to implement/integrate such solutions in Jamulus.  

The easiest way to test it is to add a client on the same machine as the server (minimum latency and drift) injecting a metronome signal. Did you try that already?

Interesting thought, could be worth a try!

[paulsijben]

I am thinking this can easily be prototyped with python or go next to jamulus and when proven integrated